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PREFACE 

This  report  describes  the  work  performed,  the  results  obtained,  and  the  conclusions  reached  during 
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moment  Laboratory  (FXG)  at  Eglin  Air  Force  Base.  Florida.  This  contract  was  performed  between  Sep¬ 
tember  1985  and  March  1988. 
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CAMP  parts  and  the  Pans  Composition  System.  Volume  II  contains  the  results  of  the  1  111.  Miss, le 
Application  development.  Volume  III  contains  Hut  results  of  the  CAMP  Annonkts  Benchmark,  Suite 
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EXECUTIVE  SUMMARY 


The  overall  objective  or  the  Common  Ada  Missile  Packages  (CAMP)  program  has  been  lo 
demonstrate  the  feasibility  and  value  of  reusable  Ada  software  parts  in  DoD  mission-critical,  real-time, 
embedded  (RTE)  applications.  As  the  name  of  the  program  implies,  the  domain  chosen  for  this 
demonstration  was  missile  operational  flight  software.  Software  applications  within  this  domain  are 
typically  constrained  in  terms  of  memory  and  timing,  and  involve  a  great  deal  of  direct  hardware  control. 
As  such,  if  reusable  Ada  parts  could  be  shown  to  be  suitable  for  these  applications,  they  would  be  suitable 
for  use  in  most  other  RTE  applications. 

CAMP  is  a  multi-year  research  program  which  has  been  sponsored  by  the  Air  Force  Armament 
Laboratory  at  Eglin  Air  Force  Base,  and  performed  by  the  McDonnell  Douglas  Astronautics  Company  - 
St.  Louis  (MDAC-STL).  The  program  was  partially  funded  by  the  Air  Force  Armament  Division,  the 
DoD  Software  Technology  for  Adaptable,  Reliable  Systems  (STARS)  Program  Office,  the  Air  Force 
Electronic  Systems  Division,  and  the  Ada  Joint  Program  Office  (AJPO). 

The  ability  to  reuse  pre-existing  software  components  to  build  new  applications  has  been  identified 
by  most  software  engineering  organizations  as  a  key  element  in  their  plans  to  reduce  software  develop¬ 
ment  costs  and  schedules.  However,  prior  to  the  mid-1980s,  few  organizations  have  been  able  to  achieve 
wide-spread,  systematic  reuse  of  software.  One  of  the  major  barriers  to  software  reuse  has  been  that 
traditional  programming  languages  were  not  designed  with  reuse  in  mind.  With  the  adoption  of  Ada  as 
the  DoD  standard  computer  programming  language  for  mission-critical  computer  systems,  many  DoD 
software  engineers  believed  that  meaningful,  systematic  software  reuse  was  feasible  for  the  first  lime. 

Ada  promotes  reuse  of  software  in  two  ways.  First,  it  is  a  highly  transportable  language.  Software 
written  in  Ada  can  be  moved  from  one  type  of  computer  to  another  relatively  easily.  This  property  of 
Ada  facilitates  reusing  software  between  applications  hosted  on  different  computers.  Second,  specific 
features  were  built  into  the  Ada  language  to  allow  a  user  lo  construct  powerful  software  components  that 
are  transportable  between  applications. 

When  Ada  was  released,  many  software  managers  and  engineers  quickly  saw  the  advantages  in 
developing  standard  reusable  parts  or  components  that  could  be  used  across  a  spectrum  of  applications 
and  computer  types.  Their  vision  was  to  treat  software  engineering  the  same  way  other  engineering 
disciplines  are  treated  —  build  customized  components  only  when  needed  and  reuse  standard  parts  when¬ 
ever  possible. 

However,  one  very  important  portion  of  the  software  engineering  community  expressed  a  great  deal 
of  skepticism  with  the  concept  of  reusable  software  —  software  engineers  building  RTE  applications. 
1Tie.se  applications  are  characterized  by  severe  memory  and  timing  constraints  and  the  need  lo  have  direct 
control  over  the  computer  and  its  attached  equipment.  The  RTE  software  community  needed  to  be 
convinced  that  reusable  Ada  parts  could  be  developed  which  were  both  sufficiently  effective  and  efficient 
for  die  types  of  applications  they  needed  lo  build.  In  the  rush  to  exploit  the  potential  of  Ada  for  reusable 
software  in  general,  no  one  was  addressing  these  RTE  applications.  There  was  a  very  good  reason  for  this 
—  developing  reusable  software  parts  foi  RTE  applications  is  much  more  difficult  than  building  reusable 
software  parts  for  non-RTE  applications. 


Given  the  pervasiveness  of  RTE  applications  within  the  DoD,  there  was  an  urgent  need  to  examine 
whether  reusable  Ada  parts  could  be  bgilt  which  were  suitable  for  use  in  RTE  applications.  In  1984,  the 
U.S.  Air  Force  addressed  this  need  by  initiating  the  CAMP  program. 

The  first  phase  of  the  CAMP  program,  the  CAMP-1  project,  was  a  12-month  effort  with  two  major 
objectives. 

•  To  determine  the  feasibility  and  value  of  reusable  Ada  software  parts  for  missile  flight  software 

•  To  determine  the  feasibility  and  value  of  automating  (fully  or  partially)  the  process  of  building  new 
missile  flight  software  systems  using  parts 

CAMP-1  started  with  a  study  to  determine  if  sufficient  commonality  existed  within  missile  flight 
software  applications  to  warrant  the  development  of  reusable  parts.  After  studying  the  operational  flight 
software  from  ten  existing  missile  systems,  the  CAMP  team  identified  2S0  common  parts  (during 
CAMP-2  this  number  grew  to  454).  Once  these  common  parts  were  identified,  their  requirements  were 
specified  and  their  architectural  designs  were  developed  in  accordance  with  DoD-STD-2167. 

Concurrent  with  the  identification,  specification,  and  design  of  the  reusable  parts,  the  CAMP  team 
perfonned  an  investigation  to  determine  which  aspects  of  building  new  software  systems  from  parts  could 
be  automated.  This  investigation  resulted  in  the  definition  and  design  of  a  tool  known  as  a  parts  composi¬ 
tion  system  (PCS)  which  would  consist  of  three  major  subsystems. 

•  A  Parts  Identification  subsystem  which  would  help  the  user  find  parts  applicable  to  his  new  ap¬ 
plication 

•  A  Parts  Catalog  subsystem  which  would  help  the  user  understand  and  manage  the  available  parts 

•  A  Component  Construction  subsystem  which  consists  of  a  set  of  tools  to  automatically  generate 
reusable  Ada  code  in  situations  where  generated  code  was  needed  for  reasons  of  efficiency, 
reusability,  or  ease  of  use.  It  also  assists  in  the  use  of  complex  generic  reusable  Ada  parts. 

While  CAMP-1  was  primarily  a  feasibility  study,  CAMP-2  was  primarily  a  technology  demonstra¬ 
tion.  The  main  goal  of  the  30-month  CAMP-2  project  was  to  demonstrate  the  technical  feasibility  and 
value  of  reusable  Ada  missile  parts  and  a  PCS  by  building  and  using  them  on  a  realistic  application. 

The  first  major  task  in  CAMP-2  was  the  construction  of  the  reusable  parts  identified  during 
CAMP-1.  A  total  of  454  production-quality,  reusable,  Ada  parts  were  coded,  tested,  and  documented  in 
accordance  with  DoD-STD-2167.  The  parts,  together  with  their  test  code,  consist  of  over  forty  thousand 
lines  of  Ada  code.  When  completed,  these  parts  were  distributed  to  over  120  government  agencies  and 
contractors.  Sections  II.  Ill,  and  VI  of  Volume  I  of  (his  Final  Technical  Report  discuss  the  constniction  of 
the  CAMP  parts  in  more  detail. 


A  prototype  of  the  parts  composition  system  tool  defined  in  CAMP-1  was  also  constructed,  tested, 
and  documented  in  accordance  with  DoD-STD-2167.  To  illustrate  the  utility  of  this  tool,  a  user  can  spend 
3  minutes  describing  his  requirements  for  a  Kalman  filter  subsystem  and  the  tool  will  generate  and  as¬ 
semble  over  1900  lines  of  Ada  code  which  efficiently  implements  this  subsystem.  Section  IV  of  Volume 
I  of  this  Final  Technical  report  describes  the  construction  of  this  prototype  in  more  detail. 

An  important  part  of  the  CAMP-2  project  was  the  construction  of  a  real  missile  navigation  and 
guidance  system  using  the  CAMP  parts  and  the  prototype  PCS  tori.  This  software,  known  as  the  11th 
Missile  Application',  consisted  of  over  21 ,000  Ada  statements  of  wh.ch  18%"  was  obtained  by  reusing  the 
CAMP  parts.  This  software  was  cross-compiled  using  an  Ada/1750A  compiler  and  executed  on  1750A 
processors  within  a  missile  simulation.  The  1 1th  Missile  Demonstration  served  as  a  proving  ground  not 
only  for  the  CAMP  parts  and  the  parts  composition  system  tool,  but  also  for  Ada/1750A  compiler  tech¬ 
nology.  Volume  II  of  this  Final  Technical  Report  describes  the  11th  Missile  Demonstration  in  more 
detail. 

Another  CAMP-2  task  was  the  development  of  a  suite  of  benchmarks  that  could  be  used  to  measure 
the  effectiveness  of  Ada  compilers  for  armonics1"  applications.  These  benchmarks  are  standard  Ada 
software  units  which  test  a  compiler's  ability  to  deal  with  realistic  armonics  situations.  Volume  III  of  this 
Final  Technical  Report  describes  the  armonics  benchmarks  in  more  detail. 

All  of  the  CAMP  products  —  the  parts,  the  prototype  PCS  tool,  and  the  Armonics  Benchmarks  — 
are  available  to  U.S.  government  agencies  and  qualified  government  contractors. 

Given  the  pathfinding  nature  of  the  CAMP  program,  it  is  not  surprising  that  many  lessons  were 
learned  concerning  Ada.  reuse,  and  the  status  of  Ada  compilers.  Section  VIII  contains  a  detailed  discus¬ 
sion  of  these  conclusions. 

The  good  news  is  that  the  Ada  programming  language  was  proven  to  be  a  good  language  for  RTE 
applications  and  for  achieving  reuse  within  these  applications.  The  entire  11th  Missile  Application  was 
constructed  using  only  21  lines  of  assembly  code,  and  the  reuse  of  standard  parts  shows  the  potential  for 
improving  productivity  by  15%.  Use  of  the  parts  and  the  parts  composition  system  showed  the  potential 
for  even  greater  productivity  gains  (up  to  28%  when  the  PCS  Kalman  Filter  Constructor  was  used  in 
addition  to  the  parts). 

The  bad  news  is  that  many  current  generation  Ada  compilers  still  have  problems  correctly  and 
efficiently  handling  the  more  advanced  features  of  Ada.  Of  particular  concern  to  the  CAMP  team  were 
the  problems  surrounding  the  handling  of  Ada  generic  units  (see  Section  VII).  If  not  corrected,  these 
problems  with  generic  units  could  have  serious  detrimental  impacts  on  reuse  within  DoD  RTE  applica¬ 
tions.  Two  actions  are  needed  to  solve  this  problem.  First,  the  Ada  validation  process  must  be  amended 
to  include  more  stringent  tests  concerning  a  compiler's  ability  to  properly  handle  complex  use  of  generic 


'The  CAMP  le.nn  used  10  missiles  to  identify  ports  and  saved  an  I  111)  missile  to  verify  the  parts,  hence  the  terminology 
'This  number  incivases  to  22%  if  the  parts  that  were  modified  arc  also  counted. 
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units.  Second,  Ada  compilers  must  include  more  powerful  global  optimization  techniques.  Until  the 
problems  are  corrected.  DoD  mission-crilic.il  RTE  Ada  projects  should  establish  a  contractual  relation¬ 
ship  will)  their  compiler  developer  in  order  to  reduce  risk  to  the  project. 

Tasking  throughput  is  currently  another  potential  problem  area  in  Ada  compiler  code  generation. 
Although  there  does  not  appear  to  be  anything  inherently  inefficient  in  the  Ada  language  requirements 
with  respect  to  tasking,  work  on  the  11th  Missile  Application  revealed  that  care  should  be  given  to 
selecting  the  kinds  of  tasking  facilities  used  in  an  application. 

The  CAMP  program  marks  the  first  practical  application  of  reusable  Ada  parts  to  DoD  mission- 
critical  RTE  applications.  The  program  demonstrated  that,  given  mature  Ada  compilers,  the  benefits  of 
software  reuse  —  reduced  software  development  cost  and  schedules  and  higher  software  quality  —  can 
be  achieved  without  sacrificing  efficiency.  If  these  benefits  can  be  achieved  in  the  missile  domain,  they 
can  be  achieved  in  other  RTE  domains. 
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SECTION  I 


INTRODUCTION 


1.  PURPOSE 

This  report  contains  a  description  of  the  work  performed,  the  results  achieved,  and  the  lessons 
learned  on  the  Common  Ada  Missile  Packages  Phase  2  (CAMP-2)  project.  CAMP  was  a  multi-year 
research  effort  in  which  the  McDonnell  Douglas  Astronautics  Company-St.  Louis  (MDAC-STL) 
demonstrated  the  feasibility  and  value  of  reusable  Ada  software  parts  in  embedded,  real-time,  mission- 
critical,  DoD  applications.  This  was  accomplished  by  (a)  building  a  library  of  efficient  and  reusable  Ada 
parts  for  missile  flight  applications,  (b)  building  a  prototype  parts  composition  system  (PCS),  and  (c) 
testing  the  parts  and  the  PCS  by  using  them  on  an  actual  missile  application. 

The  CAMP  project  has  been  sponsored  by  the  Air  Force  Armament  Laboratory  at  Eglin  Air  Force 
Base,  and  partially  funded  by  the  Air  Force  Armament  Division;  the  DoD  Software  Technology  for 
Adaptable,  Reliable  Systems  (STARS)  Program  Office;  and  the  Air  Force  Electronic  Systems  Division. 
The  Ada  Joint  Program  Office  (AJPO)  sponsored  the  initial  distribution  of  CAMP  software  to  120 
Government  agencies  and  contractors.  This  software  is  now  available  through  the  Air  Force  Defense 
Analysis  Center  for  Software  (DACS)  at  Griffiss  Air  Force  Base,  New  York. 

2.  BACKGROUND 

Reusable  software  is  rapidly  becoming  a  key  element  in  the  plans  of  many  Department  of  Defense 
(DoD)  organizations  to  bring  about  a  new  software  engineering  environment  that  will  result  in  higher 
quality  software  at  a  lower  cost.  The  recently  formed  Software  Engineering  Institute  (SEI)  believes  that 
"a  significant  portion  of  the  transition  of  new  software  engineering  technology,  the  goal  of  the  SEI,  will 
he  embodied  in  reusability  and  automation  concepts"  (Reference  1).  In  a  similar  vein,  the  DoD  Software 
Technology  lor  Adaptable,  Reliable  Systems  (STARS)  program  intends  to  " develop  a  significant  foun¬ 
dation  of  reusable  Ada  software  ...for  ...  applications  and  software  engineering  support"  (Reference  2). 
Software  reuse  has  even  been  identified  as  a  major  management  issue  by  a  DoD  directive  (Reference  3) 
on  the  management  of  computer  resources  in  defense  systems. 

While  many  factors  have  influenced  the  recent  wide-spread  adoption  of  reusable  software  within  the 
DoD,  the  most  important  factor  has  certainly  been  the  Ada  mandate.  In  1983,  the  DoD  mandated 
(Reference  4)  the  use  of  Ada  as  the  standard  programming  language  for  mission-critical  computer  sys¬ 
tems.  This  mandate  was  recently  formalized  in  a  pair  of  DoD  directives  (References  5  and  6). 

Many  software  engineers  who  in  the  past  have  doubted  the  practicality  of  software  reusability  saw 
that,  with  a  standard  language  such  as  Ada,  meaningful  levels  of  software  reuse  were  within  reach  for  the 
first  time.  However,  not  everyone  within  the  DoD  community  believes  that  software  reusability  is 
feasible.  One  very  important  group  (hat  is  not  convinced  of  the  practicality  of  reusability  is  the  real-time 
embedded  (RTE)  software  engineering  community. 

It  has  been  a  long-held  tenet  of  the  RTE  community  that  software  parts  (i.e„  components  specifically 
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written  to  be  reused)  are  not  practical  in  real-time  embedded  applications.  This  community  believes  that 
software  parts  must  be  general  to  be  reusable  and  that  generality  implies  inefficiencies.  While  the  non- 
RTE  software  engineer  is  usually  willing  to  sacrifice  some  run-time  efficiency  for  significant  increases  in 
software  quality  and  productivity,  the  RTE  software  engineer  often  cannot  afford  this  luxury.  A  typical 
RTE  software  engineer  develops  software  for  micro-computers  embedded  in  products  such  as  aircraft, 
missiles,  and  satellites.  He  cannot  freely  add  more  memory  or  upgrade  to  a  more  powerful  processor  since 
his  computer  must  comply  with  severe  limitations  on  weight,  power  requirements,  and  volume.  Even 
recent  advances  in  memory  and  processor  technologies  have  not  been  of  much  help  to  the  RTE  software 
engineer  since  the  demand  for  more  functionality  in  his  products  more  than  account  for  the  added 
capabilities  provided  by  these  technologies. 

In  order  to  convince  the  RTE  software  engineering  community  ih<  software  parts  can  work  ef¬ 
ficiently  in  the  real-time  embedded  domain,  it  is  essential  that  objective  data  be  developed  showing  that 
software  reuse  is  feasible.  It  is  not  enough  to  show  that  reusability  works  well  in  non-RTE  applications. 
Given  the  pervasiveness  of  RTE  computer  applications  within  DoD  mission-critical  systems,  it  is  impera¬ 
tive  that  questions  about  the  feasibility  of  software  parts  be  addressed  squarely  within  the  RTE  domain, 
and  preferably  by  means  of  a  realistic  demonstration.  This  was  precisely  the  goal  of  the  CAMP-2  project. 

3.  OVERVIEW  OF  THE  CAMP-1  PROJECT 

The  CAMP  program  was  initiated  in  1984  with  the  award  of  the  CAMP-1  project  to  MDAC-STL. 
The  CAMP-1  project  was  a  12-monlh  feasibility  study  with  two  major  objectives:  (a)  to  determine  the 
feasibility  and  value  of  reusable  Ada  software  parts  for  missile  flight  software,  and  (b)  to  determine  the 
feasibility  and  value  of  automating  (fully  or  partially)  the  process  of  building  new  missile  flight  software 
systems  using  parts. 

The  CAMP-1  Final  Technical  Report  contains  a  detailed  description  of  the  tasks  performed  and 
results  obtained  during  that  project.  It  can  be  obtained  from  the  Defense  Technical  Information  Center 
using  the  following  access  numbers:  AD-B-102  654  (Volume  1),  AD-B-102  655  (Volume  2),and  AD- 
B-102  656  (Volume  3).  The  major  tasks  performed  during  CAMP-1  were  as  follow: 

•  Domain  Commonality  Analysis:  The  purpose  of  this  .analysis  was  to  determine  if  sufficient  com¬ 
monality  existed  to  justify  the  development  of  reusable  Ada  missile  parts.  Ten  missiles  were 
studied  with  the  result  being  the  identification  of  over  200  reusable  Ada  software  parts.  A  Software 
Requirements  Specification  (SRS)  was  prepared  for  these  parts  in  accordance  with  DOD- 
STD-2167. 

•  Ada  Pail  Design:  After  the  parts  were  identified,  their  architectural  designs  were  developed  and 
documented  in  a  Software  Top-Level  Design  Document  (STLDD)  in  accordance  with  DOD- 
STD-2167. 

•  Part  Composition  System  (PCS)  Investigation:  The  purpose  of  this  investigation  was  to  determine 
which  aspects  of  building  new  software  systems  from  parts  could  be  automated.  The  result  of  this 
investigation  was  the  development  of  an  SRS  for  a  prototype  tool  called  the  Ada  Missile  Parts 


Engineering  Expert  (AMPEE)  System.  The  goal  of  this  tool  was  to  help  the  software  engineer  find, 
understand,  use,  and  manage  the  reusable  Ada  missile  parts. 

•  AMPEE  Design:  After  the  requirements  were  specified,  the  architectural  design  of  the  AMPEE 
system  was  developed  and  documented  in  a  STLDD. 

4.  OVERVIEW  OF  THE  CAMP-2  PROJECT 

While  CAMP-1  concentrated  on  feasibility  analyses,  CAMP-2  was  primarily  a  technology 
demonstration.  CAMP-2  was  a  30-month  project  which  began  in  September,  1985.  The  overall  goal  of 
CAMP-2  was  to  demonstrate  the  technical  feasibility  and  value  of  reusable  Ada  missile  parts  and  a  PCS 
by  building  and  using  them  on  a  realistic  application.  The  following  tasks  were  performed  on  CAMP-2: 

•  Parts  Construction:  The  purpose  of  this  task  was  to  develop  the  detailed  design  of  the  parts  which 
were  identified  during  CAMP-1,  and  to  code  and  test  the  parts.  It  was  during  this  task  that  ad¬ 
ditional  parts  were  identified,  bringing  the  total  number  of  parts  developed  to  454. 

•  AMPEE  Construction:  During  this  task,  the  detailed  design  of  the  prototype  parts  composition 
system  was  developed,  and  the  system  was  coded  and  tested. 

•  lllli  Missile  Application  Development:  This  task  involved  the  construction  of  an  actual  missile 
application  using  the  Ada  parts  and  the  AMPEE  system,  and  testing  of  the  developed  system  in  a 
1750A  hardware-in-the-loop  simulation. 

•  Armonics  Benclimarks:  The  purpose  of  this  task  was  to  use  the  CAMP  parts  to  develop  a  suite  of 
benchmarks  (hat  could  be  used  to  measure  the  effectiveness  and  efficiency  of  Ada  compilers  for 
armonics1  applications. 

The  CAMP-2  products  included  deliverable  software,  software  documentation,  and  new  software 
technology.  CAMP  software  may  be  obtained  by  certified  government  contractors  and  government 
agencies  by  writing  to  the  Air  Force  Rome  Air  Development  Center/Data  and  Analysis  Center,  (315) 
336-0937.  CAMP  documents  listed  below  with  Air  Force  Armament  Laboratory  Technical  Report  num¬ 
bers  may  be  ordered  from  the  Defense  Technical  Information  Center. 


'ARM.iniciil  elecIrONICS 
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1 .  PARTS  PRODUCTS:  Over  450  efficient,  reusable  Ada  parts  for  missile  flight  applications. 

a.  User's  Guide:  A  listing  of  all  parts,  their  purpose  and  decomposition,  other  parts  required 
for  their  use,  where  they  may  be  used  in  other  instantiations,  etc.  (AFATL-TR-88-18, 

Volume  1) 

b.  Version  Description  Document:  A  document  containing  an  inventory  of  distribution  * 

items,  installation  instructions,  and  other  information.  (AFATL-TR-88-18,  Volume  2) 

c.  Software  Product  Specification:  As-built  versions  of  all  specifications  in  accordance  with 
DOD-STD-2167.  (AFATL-TR-88-18,  Volume  3) 

d.  Top-Level  Design  Document:  The  architectural  design  (updated  from  CAMP-1)  for  the 

CAMP  parts  documented  in  accordance  with  DOD-STD-2167.  (AFATL-TR-88-18, 

Volumes  4-6) 

e.  Detailed  Design  Document:  The  detailed  design  for  the  CAMP  parts  documented  in  ac¬ 
cordance  with  DOD-STD-2167.  (AFATL-TR-88-18,  Volumes  7-12) 

f.  Test  Plan:  The  plan  by  which  the  parts  were  tested  in  accordance  with  DOD-STD-2167. 
(AFATL-TR-88-22) 

g.  Test  Procedure:  The  procedures  by  which  the  parts  where  tested  in  accordance  with  DOD- 
STD-2167.  This  was  tailored  to  include  information  that  would  usually  be  found  in  the 
Software  Test  Description  and  the  Software  Test  Report.  (AFATL-TR-88-23,  Volumes 
1-8) 

h.  Software  Development  Files:  The  working  development  notebooks  containing  source 
code  listings,  test  plan,  test  procedure,  test  code,  and  lest  results  for  the  CAMP  parts  in 
accordance  with  DOD-STD-2167. 

i.  Parts  Tape:  An  ANSII  standard  tape  containing  source  code  for  the  parts,  test  code  and 
utilities,  and  design  documents  in  machine  readable  form. 

j.  Parts  Sizing  List:  A  microfiche  containing  sizing  data  about  all  parts. 

2.  AMPEE  SYSTEM  PRODUCTS:  A  prototype  software  parts  composition  tool  including  a  parts 
catalog,  a  parts  identification  facility,  and  a  component  construction  facility. 

a.  Software  Product  Specification:  As-built  versions  of  all  specifications  documented  in  ac¬ 
cordance  with  DOD-STD-2167.  This  included  source  code  listings  for  the  AMPEE  sys¬ 
tem.  (AFATL-TR-88-I9,  Volume  I) 

b.  Top-Level  Design  Document:  The  architectural  design  (updated  from  CAMP-1)  for  the 
AMPEE  system  documented  in  accordance  with  DOD-STD-2167.  (AFATL-TR-88-I9, 

Volume  2) 
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c.  Detailed  Design  Document:  The  detailed  design  for  the  AMPEE  sjstem  documented  in 
accordance  with  DOD-STD-2167.  (AFATL-TR-88-19,  Volume  3) 


d.  Paris  Catalog:  Primed  form  of  all  data  stored  in  the  AMPEE  system  catalog.  (AFATL- 
TR -88-20,  Volumes  1-4) 

e.  User's  Manual:  A  manual  providing  the  user  with  detailed  instructions  on  the  use  of  the 
AMPEE  system.  (AFATL-TR-88-21) 

f.  Test  Plan:  The  plan  by  which  the  AMPEE  system  was  tested  in  accordance  with  DOD- 
STD-2167.  (AFATL-TR-88-22) 

g.  AMPEE  Tape:  A  tape  containing  source  code  for  the  AMPEE  system,  utilities,  and  the 
catalog  files. 

h.  Training  Plan:  A  plan  which  was  used  to  develop  training  in  the  use  and  maintenance  of 
the  AMPEE  system. 

3.  NTH  MISSILE  DEMONSTRATIOl  ■  PRODUCTS:  A  complete  missile  navigation  and  guidance 
application  built  using  CAMP  parts  and  the  AMPEE  system,  and  tested  in  a  1750A  hardware-in- 
the-loop  simulation. 

a.  Software  Requirements  Specification:  The  requirements  of  the  missile  application 
documented  in  accordance  with  DOD-STD-2167.  (AFATL-TR-88-24,  Volume  1) 

b.  Top-Level  Design  Document:  The  architectural  design  for  the  11th  Missile  system 
documented  in  accordance  with  DOD-STD-2167.  (AFATL-TR-88-24,  Volume  2) 

c.  Test  Plan:  The  plan  by  which  the  lllh  Missile  system  was  tested  in  accordance  with 
DOD-STD-2167. 

d.  Test  Report:  The  results  of  testing  the  application  in  accordance  with  DOD-STD-2167. 
This  includes  1 1th  Missile  development  evaluation. 

4.  ARMONICS  BENCHMARK  PRODUCTS:  A  self-documenting  set  of  tests  to  be  run  for  evalua¬ 
tion  of  Ada  development  and  run-time  environments  within  armonics  applications 

a.  Benclunark  Tape:  An  ANSII  tape  containing  the  benchmarks,  standard  data  files,  and 
VAX  command  procedures  for  executing  the  benchmarks  on  VAX  hardware. 

5.  OTHER  PRODUCTS 

a.  Final  Technical  Report:  Three  volumes  covering  parts  and  PCS  development,  1  Ith  Missile 
Application  development,  and  Armonics  Benchmarks  development 


b.  Monthly  Status  Reports  and  Schedule:  Management  reports 

c.  Program  Status  Reviews:  Slides  used  at  periodic  status  reviews 


cl.  SIGAda  Demonstration:  Slides  used  at  a  series  of  one-hour  presentations  of  CAMP  tech¬ 
nology 

e.  AFATL  Demonstration:  Slides  used  at  a  scries  of  three-hour  presentations  of  CAMP 
technology 

5.  ORGANIZATION  OF  THE  REPORT 

Due  to  the  large  amount  of  data  to  be  discussed  in  this  report,  it  has  been  divided  into  three  volumes. 
The  remaining  sections  of  Volume  1  are  organized  as  follows. 

•  Section  II  describes  the  development  and  testing  of  the  CAMP  parts 

•  Section  III  goes  into  additional  detail  regarding  the  inter-relationships  between  some  of  the  CAMP 
parts 

•  Section  IV  describes  the  development  and  testing  of  the  AMPEE  system 

•  Section  V  discusses  some  issues  concerning  the  Ada  language  and  their  impact  on  reusable 
software 

•  Section  VI  describes  the  methodology  used  in  designing  the  CAMP  Ada  parts 

•  Section  VII  describes  a  problem  with  current  Ada  compilers  that  potentially  could  have  a  major 
adverse  effect  on  reusable  software 

•  Section  VIII  contains  overall  conclusions  and  recommendations 

Volume  II  describes  the  development  and  testing  of  the  11th  Missile  Application.  Volume  III 
describes  the  development  and  testing  of  the  Armonics  Benchmarks. 


6 


SECTION  II 


DEVELOPMENT  AND  TESTING  OF  CAMP  PARTS 

Prior  to  the  CAMP  program,  there  were  no  successful  projects  to  carry  the  development  of  a  general 
library  of  reusable,  real-time  embedded  software  through  the  software  lifecycle.  In  fact,  except  for  tool 
catalogs  and  abstract  data  types,  no  complete  software  library  existed  in  Ada.  Therefore,  during  the  early 
stages  of  the  CAMP  parts  development,  many  new  issues  connected  with  the  development  of  reusable 
software  had  to  be  addressed. 

These  issues  included:  1  >  definition  of  terms,  2)  the  basic  structure  to  be  used  when  designing  the 
parts,  and  3)  documentation  standards  for  the  parts.  The  CAMP  team  had  to  define  a  common  terminol¬ 
ogy  because  discussing  the  number  of  parts  that  had  been  developed  or  how  parts  had  been  packaged  in 
TLCSCs  and  LLCSCs  has  little  meaning  without  a  common  understanding  of  what  constitutes  a  part,  a 
TLCSC,  and  an  LLCSC.  Development  of  the  parts  could  not  proceed  until  the  basic  design  approach  and 
structure  of  the  parts  had  been  decided.  Finally,  due  to  the  large  number  of  parts,  it  was  necessary  to 
determine  how  to  satisfy  documentation  requirements  within  practical  limits. 

I.  TERMS  AND  STRUCTURE 

One  issue  that  was  addressed  during  the  CAMP  project  is  what  actually  constitutes  a  part:  is  it  a 
package,  is  it  an  executable  unit,  is  it  a  compilation  unit,  etc.  Various  definitions  of  a  part  had  been  given 
in  the  past;  for  example,  parts  had  been  defined  as  Ada  units  (e.g.,  packages,  procedures,  functions), 
design  units,  and  code  units,  with  or  without  test  code.  While  these  were  not  incorrect  definitions,  they 
were  not  appropriate  for  CAMP.  The  criteria  established  on  CAMP  for  determining  if  a  piece  of  code 
was  a  part  are  enumerated  below.  Using  these  criteria,  454  Ada  parts  were  developed  during  the  CAMP 
program. 

1.  A  part  is  a  package,  subprogram,  or  task.  A  part  can  be  a  Top-Level  Computer  Software  Com¬ 
ponent  (TLCSC),  Lower  Level  Computer  Software  Component  (LLCSC),  or  unit.  A  TLCSC  is 
defined  as  an  outer  level  package  or  procedure  —  one  that  was  not  nested  in  another  package.  An 
LLCSC  is  defined  as  a  package  that  is  nested  in  some  other  entity,  generally  within  another 
package.  Units  arc  defined  as  nested  procedures,  functions,  or  tasks. 

2.  A  part  must  be  usable  in  a  stand-alone  fashion. 

•  It  may  with  other  parts. 

•  It  does  not  depend  on  other  packages,  subprogiams.  or  tasks  encapsulated  with  it  to  perform 
a  single  function. 
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Figure  I  shows  an  example  of  a  generic  TLCSC,  Clock_Handler,  thai  is  a  part.  The  Clock_ 
Handler  package  maintains  a  clock.  Even  though  a  single  application  may  not  require  all  of 
the  routines  in  Clock_Handler,  the  routines  could  nol  logically  exist  alone:  it  would  make 
little  sense  to  reset  a  clock  that  is  never  read.  Therefore,  the  entire  TLCSC  is  considered  a 
part. 


<vNNN\\\\S\S\S\\\VN\SN\S\S\S\\\\\\S\N\\\NV\V^ 

I  iT&SMIi  ! 

| - — - \  I 

|  Current  Time  ^  & 

S - - - 1  ! 


I 


|  Converted  Time 


|  Re$®t  Clock 

$ _ ” _ 


s - x 

$  Synchronlze_Clock  > 


$  ElapsedTlme 


;  Indicate  a  pari 
awwv  Indicate*  a  gaoartc  unit 


Figure  1.  A  Generic  TLCSC  Can  Be  A  Part 


Figure  2  shows  an  example  of  a  generic  LLCSC,  Latitude_Integralion,  that  is  a  part.  This 
package  maintains  a  latitude.  The  LLCSC  is  designated  as  a  part  because,  although  the 
Integrate  function  could  exist  on  its  own.  the  Reinitialize  procedure  could  nol. 


NORTHPOINTINGNA  VIGATIONP  ARTS 

J»\N\VVvVS\NWN\\VW\\V\\N\NVN.NW\\\\NW>^' 

IrtaflludeJnieg'riliorTri  I 

V>>  - -  .  •  } 


Reinitialize 


Integrate 


\S\\\\SSV\\N\NNNNN\NS\\N\NNV*>\\X\'»VY,\\S 

^|6ompui*_Corlols_  ^ 
Acceleration  ; 


Indicate  n  part 

\W\v  lndlcn*»*  a  q*n*r k  unH 

Figure  2.  Generic  LLCSCs  and  Functions  Can  Be  Parts 


Figure  2  also  shows  an  example  of  a  generic  procedure,  Compute_Coriolis_Acceleration, 
which  is  a  part.  Figure  3  shows  an  example  of  a  generic  package,  Vector_Operations, 


P 
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which  contains  several  subroutines,  each  of  which  is  a  part.  In  these  cases,  the  procedures, 
rather  than  any  encapsulating  packages,  are  designated  as  parts  since  the  procedures  can 
logically  exist  on  their  own. 


\V\nvnv  Indteaftt  a  ganartc  unit 

Figure  3.  A  Nongcneric  Unit  Can  Be  A  Part 

•  A  part  may  require  types  or  objects  that  have  been  encapsulated  with  it:  The  subroutines 
shown  in  Figure  3  are  parts  even  though  they  require  the  data  type.  Vectors,  defined  by  the 
Vector_Operations  package. 

3.  Organizational  packages  are  not  parts;  and  package  bodies  are  never  parts,  even  if  they  have 
processing  within  them 

Given  the  large  number  of  parts  typically  identified  during  any  domain  analysis,  it  is  useful  to 
develop  some  type  of  software  parts  taxonomy.  This  taxonomy  provides  a  means  of  classifying  parts;  it 
helps  not  only  domain  analysts,  but  also  helps  users  identify  available  parts.  Table  1  lists  the  categories  in 
the  CAMP  parts  taxonomy,  and  includes  a  description  of  the  classes  and  a  listing  of  the  TLCSCs  belong¬ 
ing  to  each  class. 

2.  PARTS  DEVELOPMENT  METHODS 

CAMP-1  included  a  domain  analysis  to  identify  commonality  between  ten  missiles  which  were 
studied.  Following  the  domain  analysis,  requirements  were  defined  for  the  common  functions  that  were 
identified,  and  parts  development  began.  Development  was  completed  during  CAMP-2.  The  develop¬ 
ment  cycle  included  top-level  design,  detailed  design,  coding,  testing,  and  documentation.  These 
development  activities  are  further  discussed  in  the  following  paragraphs. 
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TABLE  1.  CAMP  PARTS  TAXONOMY 


CATEGORY 

TLCSC  NAME 

DESCRIPTION 

Data  Constants 

WUS72_Ellipsoid_Engineering_Dot« 

WGS72_Ellipsoid_Metric_Data 

WGS72_Ellipsoid_Unitless_Datj 

Universal_ConsUnls 

Conver*ion_F»ctors 

TLCSCs  which  provide  data  constants  used 
in  a  typical  missile  application 

Data  Types 

Basic_Data_Types 

Kalman_Filter_Dala_Types 

Autopilot_Data_Types 

TLCSCs  which  provide  data  types  used  in 
other  TLCSCs  or  in  a  user  application 

Equipment  Interfaces 

Missi!e_Radar_Altimeter 

Mis*ile_R*dar_Altimeter_with_Aulopower_On 

Gock_Handler 

TLCSCs  which  provide  standard  interfaces 
to  specific  hardware  components  or  to 
general  classes  of  hardware 

Navigation 

Common_Navigation_Parts 

Wander_Azimuth_NavigationJParU 

North_Pointing_Navigation_Parls 

Dircction_Cosine_Matrix_Oper*tions 

TLCSCs  which  provide  the  basic 
functionality  of  a  navigation  subsystem 

Kalman  Filter 

Kslman_Filfcr_Common_Part*  TLCSC 
Kalman_Fi!ter_Compacl_H_Paris  TLCSC 
K«iman_Filter_Complicated_H_P«rts  TLCSC 

TLCSCs  which  provide  common  Kalman 
filter  functions 

Outdance  and  Control 

Waypoint_Steering 

Autopilot 

TLCSC*  which  provide  the  basic 
functionality  of  a  guidance  and  control  aub- 
ayatem 

Nonguidance  Control 

Air_DsU_Psrts  TLCSC 

Fuel_Con»rol_Part«  TLCSC 

TLCSCs  which  provide  the  basic 
functionality  of  a  control  subsystem  for 
operations  outside  of  the  guidance  area 

Mathematical 

Coordinale_Vector_Matri*_Algehra 

Oeneral_  Vector_Matri  x_Algebra 

Slandard_Trig 

Oeometric_Operations 

Signal_Processing 

Polynomials 

OeneralPurposeMatli 

Unit_Conversions 

Extemal_l"'omi_Conversioii_Twos_C'omplemenl 

Quale  rnion.Ope  rations 

TLCSCa  which  provide  a  variety  of  uaeful 
mathematical  functions  auch  a*  coordinate 
and  matrix  algebra,  trigonometric,  and  sig¬ 
nal  processing  functions 

Abstract  Mechanisms 

Abstract_Data_Stmctures 

TLCSCs  which  provide  abstract  data  struc¬ 
tures  and  processes 

Oeneral  Utilities 

Genera  l_Utililies 

Communicalion_Parts 

TLCSCs  which  provide  other  functions 
needed  for  missile  or  other  weapons  system 
operation 

a.  Design  and  Code 

On  CAMP,  lop-level  design  consisted  of  the  package  specifications  for  all  the  CAMP  parts 
TLCSCs,  including  the  specifications  for  all  exported  LLCSCs  and  units,  as  well  as  the  definition  of  all 
exported  data  types,  constants,  and  exceptions. 

Detailed  design  and  coding  phases  were  merged  through  the  use  of  Ada  as  the  design  language 
The  primary  purpose  of  the  program  design  language  (PDL),  Ada  design  language  (ADL),  and/or  pseu¬ 
docode  developed  during  detailed  design  is  to  improve  understanding  of  the  software  by  providing  ad¬ 
ditional  information  that  is  an  appropriate  level  of  abstraction  above  (he  code.  The  key  here  is  that 
detailed  design  should  be  a  higher  level  of  abstraction  than  the  code.  If  it  is  not,  then  there  may  be 
excessive  duplication  of  effort  during  the  detailed  design  and  coding  phases.  There  were  certain  charac- 


10 


teristics  of  Ihe  CAMP  project  which  led  to  the  conclusioi  that  it  was  appropriate  to  go  directly  from 
top-level  design  to  code  for  development  of  the  CAMP  parts.  These  characteristics  are  discussed  below. 


•  Low-level  requirements:  The  requirements  for  many  of  the  parts  were  specified  at  a  very  low  level. 
The  algorithms  to  be  used  in  many  of  the  math  parts,  for  example,  were  completely  specified  during 
die  requirements  phase.  There  was,  therefore,  no  need  to  repeat  these  algorithmic  requirements  in 
the  detailed  design. 

•  Parts  were  built  of  other  parts:  Many  of  the  high-level  CAMP  parts  were  designed  to  accept  other 
parts  as  generic  parameters.  The  highest  level  parts  directly  instantiate  Ihe  CAMP  parts  required  to 
perform  lower  level  operations.  These  design  aspects  of  the  CAMP  parts  are  further  discussed  in 
Sections  III  and  VI. 

An  example  of  parts  instantiating  other  parts  is  shown  in  Figure  4  which  contains  the  detailed 
design/code  for  the  Kalman_Filter_Complicated_H_Parts.Sequenlially_Updated_Covariance_ 
Malrix_and_State_Vector.Update  procedure.  The  English  pseudocode  for  this  procedure  would  be 
similar  to  the  following: 

for  each  measurement  in  the  stale  vector  loop 
compute  K  (Kalman  gain) 
update  P  (error  covariance  matrix) 
update  X  (state  vector) 
end  loop 

The  actual  code  for  this  procedure  would  be  very  similar  to  the  pseudocode  if,  as  in  the  CAMP 
parts,  the  calculations  of  a  new  K,  P,  and  X  consisted  simply  of  calls  to  other  routines.  This 
similarity  can  be  seen  by  comparing  the  above  pseudocode  with  the  actual  code,  shown  in  Figure  4, 
which  contains  nothing  more  than  a  loop  and  three  subroutine  calls. 

•  Parts  are  small:  The  CAMP  parts  tend  to  be  small,  less  than  36  lines  of  code  on  average,  and, 
therefore,  relatively  simple.  The  need  for  high-level  comments  frequently  decreases  as  the 
simplicity  of  the  code  increases.  This  can  be  seen  in  Figures  5  and  6  which  contain  simple  and 
relatively  complex  routines,  respectively.  Figure  5  shows  a  piece  of  code  which  sets  all  elements  of 
a  symmetric,  full-storage  matrix  to  0.0.  The  code  for  this  procedure  is  quite  simple  and  self- 
explanatory;  it,  therefore,  contains  no  comments  other  than  those  in  its  code  header.  Figure  6,  on 
the  other  hand,  contains  a  more  complicated  piece  of  code  which  subtracts  a  symmetric,  full-storage 
matrix  from  an  identity  matrix.  Because  of  the  complexity  of  this  code,  high-level  comments,  in 
addition  to  those  contained  in  its  code  header,  were  required.  This  ratio  of  comments  to  code  for 
this  piece  of  code  is  better  than  1 :2. 

While  this  merging  of  the  detailed  design  and  coding  phases,  hereafter  referred  to  as  detailed 
design,  is  not  appropriate  for  all  applications,  it  was  appropriate  for  development  of  the  CAMP  parts. 

The  primary  steps  during  ihe  design  phases  are  shown  in  Table  2. 

Design  walkthroughs  were  attended  by  all  members  of  the  CAMP  parts  team  and  occasionally 
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ptckftg*  body  Kalman_riltar__Coraplicatad_H_Part  a  1* 

function  Computa_!Calman_Gain  .  .  . 
prooadura  Opdata_Zrror_Covarianca_Matrix  .  .  . 
prooadura  Opd*ta_Stata_Vactor  .  .  . 

paoltaga  body  Saquant  lally_Opdata_Covarianca_Mat  rix_and_Stata_Vactor  ia 
K  :  K_Column_Vaotora; 

function  Conq?uta_K  ia  naw  Coirputa_lCalm»n_Gain  .  .  . 
prooadura  Op  da  t  a_P  ia  naw  Opdata__Error  Covarianca_Matrix  .  .  . 
procadura  OpdataX  ia  naw  Opdata_Stata_Vactor  . . . 

prooadura  Op  data  (P  :  in  out  P_Matrioaa; 

X  :  in  out  3tata_Vaotora; 

Z  :  in  Maaauranant_Vaotora; 

Conplioatad_B  :  in  B_Matrioaa; 

Kaaauramant_Varianca  :  in  Maaauraaant  Varlanca_Vactor)  ia 

bagin 

for  Maaauraraant_Nuinbar  in  Maaa.iramant  Indicaa  loop 

K  :«  Cong>uta_K  (P  «>  P, 

Maaauramant_Humbar  *>  Maaauraaant_Muabar, 

Compllcatad_B  ■>  Conplioatad_B, 

Maaauramant_Varianca  «*>  Haaauraaant_Varianoa)  ; 

Opdata_P  (P  «>  P, 

Maaauramant_Humbar  ->  Maaauramant_Nuabar, 

K  ->  K, 

ComplioatadH  “>  Co«q>licatad_H)  ; 

Opdata  X  (X  ->  X, 

Z  ->  Z, 

K  ->  K, 

Maaauraaant_Numbar  ->  Maaauramant_Nunbar, 

Complicatad_B  ">  Compllcatad_B)  ; 

and  loop; 
and  Opdata; 

and  Saquantially_Opdata_Covarianca_Matrix_and_Stata_Vactor; 
and  Kalman_jriltar_Compllcatad_B_Parta; 

Figure  4.  For  High-Level  Parts,  Detailed  Design  is  Code 


aaparata  (Ganaral_Vactor_Matrix_Algabra. 

Symmatric_Full_9toraga_Matrix__Oparationa_Onconat  rained) 
procadur*  Sat_To_Zaro_Matrix  (Matrix  :  out  Matricaa)  ia 

bagin 

Matrix  :=  (othara  =»>  (othara  =>  0.0)); 
and  Sat  To  Zaro  Matrix; 


Figure  5.  Simple  Parts  Require  Few  Comments 
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function  0ubtraat_fram_Xdentity  (Input  :  Matrices)  return  HitrlMC  is 


—  - -declaration  •notion 


Answer  :  Mat r ion*  (Input' RATCB(l)  ,  Input '  RAJftZX  (2)  )  ; 
Col  :  Col  Indian* ; 

Col_Count  :  POBTtZVB; 

Row  :  Row  Indian*; 

Row_Count  :  FO0TMVB; 

0  Col  ;  Col_Indian*; 

0>o«  :  Row~Indiaes; 


- *b«gin  function  Subtrsct_f rem_Ident ity 


begin 

—  **uk*  *um  input  matrix  i*  n  touir*  matrix 
if  Input' LBRaTR(l)  -  Input'  um9TH  (2)  than 

--  --will  subtract  input  matrix  from  an  identity  matrix  by  flrat 
--  --subtracting  all  nlmmnot*  from  0.0  and  than  adding  1.0  to  tha 

—  --diagonal  elements; 

—  -  --wham  doing  tha  subtr  nation,  will  only  calculate  tha  remain  da  r 

--for  tha  alamants  in  tha  bottom  half  of  tha  matrix  and  will  simply 
--do  a**ignmant*  for  the  symmetric  alamants  in  tha  tap  half  of  tha 
--matrix 

Row_Couat  :■  1  ; 

--  - col  will  go  aoross  the  columns  as  Row  goat  down  tha  rows; 

-  -  wTll  mark  ooluxn  containing  tha  diagonal  a  1  assent  for  this  row 
Row  ;a  Input '  FIR0T  (1 )  ; 
s_coi  :»  input 'r hut  (2)  ? 

Do_«  T9  ry_Row  • 

“loop  — 

Col_Count  :*  1; 

- -8  Row  will  go  down  tha  rows  as  Col  goas  aoross  tha  oolmans; 
--wEsn  paired  with  8  Col  will  mark  tha  syaamtrio  counterpart 
--to  tha  a  lament  being  referenoed  in  tha  bottom  half  of  the 
--matrix 

Col  Xnput'rXRJT(2)  ; 

0  Row  Input ' fZRJT  (1 )  ; 

0ubtract_*  lament  s_rrom_*aro : 
loop 

--  --perform  subtraction  on  olomont  in  bottom  half  of  matrix 

Answer  (Row,  Col)  :■  -  Input  (Row,  Col)  ; 

•-exit  loop  sf tar  diagonal  element  has  bean  reached 
exit  0ubtreat_Blamants_Vrom_ftero  whan  Col  Count  ■ 

Kow_Count : 

--assign  waluas  to  symmetric  olassants  in  top  half  of  matrix 
--(dona  after  oheak  for  diagonal,  since  diagonal  alamants 
--  —  don't  him  a  symmatrlo  counterpart) 

Answer  (0_R©w,  0__Col )  :■  Answer  (Row,  Col) ; 

- - lnoramamt  warlablas 
Col_Count  :•  ColjCouat  4*  1; 

Col  :■  Col_Indloes' 0OCC (Col)  ; 

0_Row  ; ■  Row_Zndioos '  0PCC  ( 0_Row)  ; 

ond  loop  Subtract  K laments  From  Eero; 

--add  one  to  tha  diagonal  element 

Answer  (Row,  Col)  :■  Answer  (Row,  0_Col)  +  1.0; 

oxlt  Do_Bwery  Row  whan  Row_Count  »  Input '  LKROTIi  ( 1)  ; 

Row  Count  :■  low  Count  +  1  ; 

Row  : ■  Row  'Indians '  0OCC (Row) ; 

0_Col  :  ■  Col  ^Indices '  0OCC  ( 0_Col )  ; 

and  loop  Do_ETery_f ow; 

also 

raise  Dimension  Error; 
and  if; 

return  Answer; 

and  0ubtrect_from_ldentlty; 


Figure  6.  Complicated  Parts  Require  More  Comments 
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TABLE  2.  DESIGN  STEPS 


STEP 

DESCRIPTION 

i. 

Assignment  of  requirements  to  the  TLCSC 

2. 

Completion  of  top-level  design,  along  with  header  information  (see  Section 
11.2.0 

3. 

Preparation  of  a  software  development  file  (SDF)  (see  Section  11.2.0 

4. 

Top-level  design  walkthrough 

5. 

Completion  of  detailed  design,  along  with  header  information  (see  Section 
*1.2.0 

6. 

Preparation  of  test  procedure  /plan  (see  Section  II.2.b) 

7. 

Detailed  design  walkthrough 

by  members  of  the  parts  composition  team.  The  design  presented  for  walkthrough  was  reviewed  to 
ensure  conformance  with  requirements,  conformance  of  design  with  existing  design  and  coding  standards, 
consistency  with  other  parts,  completeness  of  documentation,  and  conformance  of  code  headers  to  docu¬ 
ment  generation  tool  requirements  (see  St,  >n  II.2.e.(4)). 

b.  Tesling 

The  testing  phase  of  the  life  cycle  began  after  completion  of  detailed  design  and  prior  to  the 
detailed  design  walkthrough.  During  this  phase,  a  test  plan  and  procedure  for  Ihe  TLCSC  were  prepared 
for  later  review  by  the  CAMP  parts  team  at  the  detailed  design  walkthrough.  Following  completion  of  all 
design  walkthroughs  and  implementation  of  walkthrough  action  items,  a  part  was  given  to  a  tester  for 
unit/integration  testing. 

Unit  and  integration  testing  of  the  CAMP  parts  were  combined  into  a  single  phase  because  of 
the  bottom-up  approach  taken  to  testing.  All  parts  requiring  other  parts  directly  or  designed  to  use  them 
through  generic  parameters  were  actually  tested  using  the  supporting  parts  which  had  already  passed 
testing.  This  approach  shortened  the  testing  phase  by  eliminating  the  need  to  write  code  stubs  and  by 
eliminating  the  need  to  first  test  a  part  in  isolation  and  then  retest  it  using  the  parts  themselves. 

Most  parts  required  several  iterations  through  the  testing  cycle  illustrated  in  Figure  7.  The 
majority  of  testing  errors  resulted  from  errors  in  the  test  procedures.  Much  less  frequently,  errors  were 
found  in  the  parts.  On  rare  occasions,  errors  were  found  in  the  supporting  parts  which  had  already  been 
tested.  If  an  error  were  found  in  a  part,  whether  directly  or  indirectly,  it  was  returned  to  the  original 
designer  for  modifications  and  sent  through  the  testing  cycle  again.  When  a  TLCSC  successfully  passed 
testing,  it  was  placed  under  configuration  control  (see  Section  II. 2  d)  and  compiled  into  the  main  CAMP 
parts  library. 
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Figure  7.  CAMP  Paris  Testing  Cycle 


c.  Maintenance 

During  the  CAMP  project,  parts  were  modified  to  provide  both  enhancements  and  corrections. 
Changes  to  the  CAMP  parts  were  governed  by  a  Configuration  Change  Control  Board  (CCCB)  that  was 
put  into  effect  after  parts  development  was  complete.  The  CCCB  consisted  of  the  program  manager  and 
the  heads  of  the  1 1th  Missile  and  parts  development  teams.  On  occasion,  members  of  the  parts  composi¬ 
tion  system  team  and  additional  members  of  the  parts  development  teams  participated  in  board  discus¬ 
sions.  The  CCCB  was  tasked  to  determine  whether  a  proposed  modification/enhancement  to  a  part  should 
be  made.  The  outcome  of  the  decision  was  based  on: 

•  The  scope  of  the  change:  Was  it  a  minor  change  or  a  major  one?  Was  it  specific  to  the  11th 
Missile  or  general  enough  to  be  relevant  (o  other  missile  systems? 

•  Purpose  of  the  change:  Was  it  to  correct  an  error  (errors  were  always  corrected)  or  provide  an 
enhancement? 

•  Schedule  constraints 

The  need  for  corrections  to  the  CAMP  parts  was  determined  at  several  points  during  the  life 
cycle  of  the  parts.  Corrections  due  to  errors  detected  during  unit  and  integration  testing  are  discussed  in 
Section  11.2.b.  Occasionally,  errors  were  detected  in  pails  that  had  been  successfully  unit  and  integration 
tested.  These  errors  were  generally  due  to  incorrect  requirements  and  were  identified  through  the  lllh 
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Missile  Application  use  of  the  CAMP  parts,  as  well  as  through  reviews  of  the  parts  by  other  McDonnell 
Douglas  software  projects  for  potential  use  in  their  systems.  These  errors  were  corrected  as  they  were 
discovered.  The  affected  parts  were  then  retested  and  baselined  again. 

During  the  development  of  the  1 1th  Missile  Application,  it  was  found  that  some  parts,  while  not 
incorrect,  were  inappropriate  for  use  on  that  project.  Some  of  these  inadequacies  were  due  to  require¬ 
ments  and  some  were  due  to  design  decisions.  These  pro!  ems  were  handled  in  one  of  the  following 
ways: 

•  Baselined  parts  were  modified:  This  course  of  action  was  chosen  if  it  was  determined  that  the  parts 
were  inappropriate  not  only  for  the  1 1th  Missile  Application,  but  also  for  other  missile  applications. 
For  example,  all  the  Kalman  filter  packages  were  modified  because  it  was  found  that  the  generic 
parameters  did  not  allow  sufficient  flexibility, 

•  Additional  parts  were  created:  The  algorithms  for  some  of  the  parts  made  assumptions  that  were 
not  appropriate  for  the  lllh  Missile  Application.  For  example,  some  of  the  navigation  parts  take 
advantage  of  the  fact  that  for  small  angles,  the  sine  of  the  angle  is  approximately  equal  to  the  angle 
itself.  This  assumption  increases  efficiency  by  eliminating  the  need  to  calculate  an  arcsine  and 
produces  satisfactory  results  for  some  missile  applications.  This  assumption,  however,  was  not 
appropriate  for  (he  11th  Missile  Application  and  potentially  not  for  other  missiles  either.  Con¬ 
sequently,  new  parts  were  created  which  used  the  arcsine  instead  of  the  approximation. 

•  1  llh  Missile  team  modified  their  own  versions  of  the  parts:  In  some  cases,  the  required  modifica¬ 
tions  were  specific  to  the  I  llh  Missile  Application  and.  therefore,  did  not  warrant  modifications  to 
the  baselined  CAMP  parts.  In  these  instances,  the  1  Ith  Missile  team  modified  their  own  versions  of 
the  parts  as  required.  A  further  discussion  of  this  can  be  found  in  Volume  II. 

d.  Configuration  Management 

Two  libraries  were  created  to  aid  in  configuration  management  of  all  CAMP  parts.  These 
libraries  were  created  under  the  DEC  Ada  Compilation  System  (ACS)  and  Configuration  Management 
System  (CMS).  The  ACS  library  contained  compilations  of  the  current  versions  of  all  baselined  CAMP 
parts.  The  CMS  library  contained  the  ASCII  files  for  all  baselined  CAMP  parts.  Both  of  these  libraries 
were  controlled  by  one  member  of  the  parts  team:  the  parts  librarian.  Read  access  was  given  to  all 
members  of  the  CAMP  team,  but  only  the  CAMP  librarian  could  place  elements  in  these  libraries.  The 
ACS  and  CMS  tools  are  further  discussed  in  Sections  H.2.c.(  I )  and  Il.2.e.(3),  respectively. 

The  CAMP  librarian  was  responsible  for  baselining  all  CAMP  TLCSCs.  A  TLCSC  was 
baselined  when  it  had  successfully  passed  its  testing  phase,  all  source  code  documentation  had  been 
updated  to  include  testing  information,  and  the  Software  Development  File  (SDF)  (see  Section  11.2. D  had 
been  brought  up  to  date. 
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When  a  TLCSC  was  first  placed  under  configuration  control,  all  files  pertaining  to  the  TLCSC 
were  placed  in  the  CMS  library;  these  files  included  those  listed  in  Table  3.  The  TLCSC  was  then 
compiled  into  the  ACS  library. 


TABLE  3.  ITEMS  UNDER  CONFIGURATION  MANAGEMENT 


CONTENTS 

All  source  code  files  for  TLCSC 

Test  procedure 

Test  plan 

All  source  code  files  containing  test  c  ode 

Input  data  for  tests 

Si 

Expected  results  for  tests 

B 

Results  of  testing 

DEC/Test  Manager  command  files  used  to  organize  tests 

If  a  TLCSC  required  modifications,  the  CAMP  librarian  would  reserve  the  files  requested  by 
the  person  responsible  for  making  the  modifications.  The  files  were  checked  back  into  CMS  when  the 
modifications  were  complete,  the  TLCSC  was  successfully  retested,  and  the  source  code  documentation 
and  SDF  were  updated. 

When  rebaselining  a  modified  TLCSC,  the  modified  files  were  placed  back  into  the  CMS 
library;  new  files,  if  any,  were  placed  under  configuration  control  by  placing  them  in  the  CMS  library;  the 
modified  TLCSC  was  compiled  into  the  ACS  library;  and  any  TLCSCs  whose  compilations  depended 
upon  the  newly  compiled  TLCSC  were  recompiled. 

c.  Tools 

Software  tools  were  used  by  all  members  of  the  CAMP  team  during  all  phases  of  the  project. 
This  was  a  critical  component  in  the  increased  productivity  experience  on  the  CAMP  project.  Some  of 
the  tools  were  provided  by  commercial  vendors  and  satisfied  standard  needs  such  as  library  management, 
configuration  management,  symbolic  debugging,  editing,  and  text  processing.  In  other  areas,  such  as 
document  production,  requirements  for  tools  were  identified  which  could  not  be  met  with  commercial 
products,  and  in-house  tools  were  developed. 
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(I)  Design  iind  ('ode  Development  Tools 

All  CAMP  Ada  development  look  place  using  the  Ada  programming  support  environment 
(APSE)  provided  by  Digital  Equipment  Corporation  (DEC).  This  development  environment  includes:  1) 
the  VAX  Ada  compiler:  2)  the  Ada  Compilation  System  (ACS)  which  serves  as  the  program  library 
manager  and  provides  an  interface  to  the  compiler  and  linker;  and  3)  a  symbolic  debugger. 

The  development  environment  provided  by  the  Ada  Compilation  System  facilitated  the 
development  of  parts  by  multiple  engineers.  The  ability  to  create  sublibraries  allowed  the  creation  of  one 
parent  library  containing  all  tested,  baselined  parts,  and  separate  sublibraries  for  the  untested  software 
under  control  of  the  parts  developers.  The  use  of  one  parent  and  multiple  sublibraries  allowed  all  parts 
developers  immediate  access  to  baselined  CAMP  |iarts.  It  also  gave  the  developers  immediate  access  to 
all  parts  which  were  modified  and,  therefore,  recompiled. 

Unlike  other  development  environments,  ACS  does  not  impose  the  restriction  of  requiring 
library  unit  specifications  and  bodies  to  be  compiled  into  the  same  library.  The  compilation  system  also 
allows  units  to  be  entered  via  pointers  from  one  library  or  sublibrary  into  another.  This  allows  parts 
physically  located  in  another  library  to  be  shared  by  reference.  This  method  of  entering  rather  than 
compiling  a  referenced  unit  into  a  library  has  the  advantage  of  avoiding  the  problem  of  compiling  against 
an  obsolete  version. 

The  usefulness  of  DEC’S  Ada  Compilation  System  is  enhanced  by  its  integration  with  both 
the  DEC  Code  Management  System  (CMS)  and  the  symbolic  debugger.  This  allows  ACS  to  fetch  files 
from  the  CMS  library  for  recompilations.  It  also  allows  the  symbolic  debugger  to  fetch  files  from  the 
Ada  library  in  order  to  display  source  code  lines  during  a  debugging  session.  Both  of  these  features  were 
used  extensively  during  CAMP. 

Another  useful  and  frequently  used  feature,  is  the  ability  of  the  ACS  library  manager  to 
automatically  perform  recompilations  of  obsolete  units.  When  invoking  this  feature,  it  is  possible  to 
indicate  that  a  unit  is  to  be  considered  obsolete  if,  in  addition  to  the  normal  rules  of  compilation,  the 
creation  date  of  the  latest  source  code  file  is  more  recent  than  the  latest  object  code.  This,  along  with 
integration  of  ACS  with  CMS,  allows  the  library  manager  to  retrieve  files  from  CMS  for  recompilation 
whenever  a  new  version  of  the  part  is  baselined. 

(2)  Testing  Tools 

The  testing  phase  of  a  part's  life  cycle  included  the  identification  and  organization  of 
required  tests,  preparation  of  a  test  plan  and  procedure,  preparation  of  test  code,  and  actual  testing  of  the 
part.  The  tools  which  were  used  to  assist  with  all  of  these  phases  are  discussed  below. 

Test  Manager 

The  VAX  DEC/Test  Manager  tDTM)  is  a  tool  developed  by  DEC  to  assist  in  the  organiza¬ 
tion  of  tests,  selection  of  tests  for  execution,  and  review/verificalion  ol  test  results.  It  was  used  on  CAMP 
to  organize  tests  and  assist  in  preparation  of  the  test  plan. 
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Tests  were  generally  organized  by  creating  a  group  of  tests  for  each  TLCSC  and  then 
creating  subgroups  for  each  LLCSC  within  a  given  TLCSC.  The  tests  and  groups  were  created  by  writing 
job  control  files  containing  the  appropriate  DTM  commands  and  then  submitting  these  files  to  the  test 
manager.  While  DTM  does  have  interactive  capability,  it  was  felt  that  the  number  and  size  of  the  re¬ 
quired  commands  were  too  great  for  this  capability  to  be  practically  applied,  particularly  considering  the 
number  of  tests  required  for  even  a  medium-sized  TLCSC. 

Following  creation  of  the  appropriate  tests  and  groups  for  a  TLCSC,  DTM  could  be 
queried  to  show  all  the  tests  and  groups  for  a  particular  case.  A  tool  was  written  to  take  this  output  and 
create  the  tables  which  were  used  to  document  the  tests  for  the  test  plan  document. 

An  attempt  was  made  to  use  the  DECfTest  Manager  for  testing  of  the  CAMP  parts,  but 
DTM  proved  unacceptable  since  it  allowed  no  tolerance  in  the  output.  The  results  of  a  test  had  to  be 
exactly  what  were  expected  or  the  test  failed.  For  example,  if  the  expected  result  was  2.0  and  the  actual 
result  was  1.9999999999  or  2.00000000001,  the  test  failed.  Therefore,  use  of  DTM  for  the  execution  of 
tests  was  discontinued 

Record  Results  and  Retrieval  Operations  packages 

During  the  early  stages  of  CAMP  parts  testing,  tools  were  developed  to  assist  with  the 
execution  of  tests.  These  tools  consisted  of  the  Record_Resulls  and  Retrieval_Operations  packages. 

The  Record_Rcsults  package  was  designed  to  control  the  output  file,  retrieve  data  from  the 
expected  results  file,  format  output  to  the  results  file,  and  check  the  results  of  each  test.  It  consisted  of 
several  subroutines  and  several  generic  packages.  The  subroutines  dealt  with  initializing  the  recording 
operations,  opening  and  closing  the  output  file,  textual  output  to  the  file,  formatting  the  file,  and  tailoring 
heading  information.  The  generic  packages  were  designed  to  handle  floating  point,  integer,  and  enumera¬ 
tion  data  types  and  contained  the  actual  recording/analysis  routines. 

The  recording/analysis  routines  were  overloaded  to  allow  for  variations  in  the  recording 
operations  themselves:  whether  the  description  was  to  be  a  textual  description  or  simply  a  running  count 
of  the  number  of  tests  performed;  whether  the  expected  value  was  being  sent  to  the  routine  or  should  be 
read  from  an  expected  results  file.  Each  of  the  routines  had  a  parameter  controlling  the  tolerance  to  be 
used  forjudging  every  value  recorded  for  each  test.  A  value  was  considered  acceptable  if: 

abs  (Actual  -  Expected)  <=  abs(Expected)  *  Tolerance 
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The  recording  routines  were  able  to  skip  over  extraneous  text  when  retrieving  data  from 
the  expected  results  file.  Figure  8  shows  an  excerpt  from  the  expected  results  file  used  for  testing  the 
Waypoin(_Steering  TLCSC.  It  was  created  by  retaining  applicable  sections  from  the  test  procedure.  The 
recording  routines  had  the  capability  to  go  into  a  file  such  as  the  example,  skip  over  the  extraneo  is  text, 
read  the  floating  point  values  for  UN_B,  again  skip  over  extraneous  text,  and  read  the  enumeration  values 
for  the  Start_Test  function  without  having  any  knowledge  of  the  textual  format  of  the  file.  Being  able  to 
do  this  had  several  benefits: 

•  Testing  was  simplified:  Since  the  expected  results  file  was  a  trimmed-down  version  of  the  lest 
procedure,  complete  with  pertinent  paragraph  headings,  it  was  easy  to  tell  whether  the  numbers 
being  read  for  a  particular  lest  were  the  ones  that  were  supposed  to  be  read. 

•  Time  was  saved:  There  were  definite  advantages  to  being  able  to  have  extra  text  in  the  expected 
results  file,  but  it  would  have  been  inconvenient  to  have  required  a  rigid  formal  or  to  have  had  the 
test  code  know  the  textual  layout  of  the  file.  By  creating  routines  capable  of  skipping  over  super¬ 
fluous  data  without  knowing  the  format,  time  was  saved.  Additional  time  savings  were  also  real¬ 
ized  by  creating  a  tool  capable  of  assisting  in  the  job  of  stripping  the  test  procedure  to  create  the 
expected  results  file. 

x.2.2  FOR  MAI.  TEST  X.X.X  UPDATE  PROCEDURE 
x.2.2.5  OUTPUT 

Execution  should  generate  the  following  output: 

—first  set  of  results 

0. 28 7_603_7 34_ 1 97  <U97_187_I32_18*  -0.937_536_950_976  ~UN_B  values 
x.9.2  FORMAL  TEST  X.X.X  -  S  TARTTEST  FUNCTION 
x.9.2. 5  OUTPUT 

Execution  should  generate  the  following  output: 

Not_Turning 

Turning 

Figure  8.  Sample  Expected  Results  File 

Text  Formatter 

Digital  Standard  Runoff  (DSR)  is  a  text  formatting  tool  supplied  by  the  Digital  Equipment 
Corporation.  It  processes  source  files  into  formatted  text,  optionally  creating  a  tabic  of  contents.  DSR  was 
used  on  CAMP  for  the  creation  of  test  procedures,  the  top-level  design  document,  and  the  detailed  design 
document. 

Symbolic  Debugger 

The  DEC  Ada  Compilation  System  includes  a  symbolic  dcbuggei  The  functions  of  the 
VAX  symbolic  debugger  include  the  ability  to  run  programs,  set  breakpoints,  and  execute  individual 
instructions;  examine,  set,  and  evaluate  program  data;  and  show  a  trace  of  active  calls  at  the  current 
program  counter  location,  ft  permits  debugging  in  a  screen  mode  which  placed  source  code  in  one 
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window  and  debugger  commands  and  output  in  another.  Since  the  debugger  recognizes  Ada  constructs,  it 
was  possible  to  ask  for  the  current  value  of  a  component  of  an  array  or  record,  or  to  ask  it  to  evaluate  the 
attribute  for  some  object  or  type. 

The  symbolic  debugger  did  have  a  few  limitations: 

•  Variable  initialization:  The  symbolic  debugger  apparently  initializes  some  variables  when  it  is 
invoked;  this  causes  difficulties  in  locating  program  errors.  For  example,  one  program  was  abnor¬ 
mally  terminating  due  to  a  constraint  error.  When  an  attempt  was  made  to  identify  the  problem 
using  the  symbolic  debugger,  the  program  ran  successfully.  It  took  several  iterations  of 
running/debugging  before  it  was  realized  that  the  program  ran  successfully  in  the  debugger  because 
the  debugger  was  correctly  initializing  an  otherwise  uninitialized  variable. 

•  Scope:  On  occasion,  particularly  if  the  program  was  large  and  contained  many  instantiations,  the 
debugger  would  not  show  the  source  code  for  a  unit  because  some  other  unit  (one  not  being  stepped 
through)  was  not  in  its  active  scope.  This  frequently  made  it  impossible  to  debug  the  routine  using 
the  debugger. 

In  spite  of  these  problems,  the  debugger  was  a  useful  tool  and  was  used  frequently  during 
CAMP  by  both  the  parts  and  1 1  tit  Missile  teams. 

(3)  Configuration  Management  Tools 

The  Code  Management  System  (CMS)  provided  by  Digital  Equipment  Corporation  was 
used  for  configuration  management  of  the  CAMP  parts.  This  tool  and  its  use  are  further  discussed  in 
Section  ll.2.d. 

(4)  Documentation  Tools 

Tools  to  aid  in  the  creation  of  top-level  and  detailed  design  documents  were  needed  for  the 
following  reasons: 

•  It  was  anticipated  that  the  top-level  and  detailed  design  documents  for  the  CAMP  parts  would  be 
very  large  due  to  the  number  of  CAMP  parts  and  the  amount  of  documentation  on  each  one. 

•  It  was  des:rable  to  eliminate  the  need  to  maintain  three  sets  of  documentation:  source  code  files, 
top-level  design  document,  and  detailed  design  document.  Since  all  of  the  information  was  already 
contained  in  the  source  code  files,  it  was  preferable  to  maintain  only  them  and  simply  recreate  the 
design  documents  as  necessary. 
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For  these  reasons,  comment  extractor  tools  were  developed  to  "ielp  create  Section  3.6 
(Top-Level  Design)  of  the  DoD-STD-2167  Top-Level  Design  Document  and  Section  3.3  (Detailed 
Design)  of  the  DoD-STD-2167  Detailed  Design  Document.  The  comment  extractors  generate  the  Digital 
Standard  Runoff  (DSR)  text  formatting  commands  required  to  produce  for  the  design  documents  and 
extract  the  appropriate  information  from  the  source  code  headers  for  each  of  the  paragraphs.  Figures  10 
and  1 1  show  which  sections  of  the  source  code  headers  were  placed  in  the  design  documents. 

(5)  Miscellaneous  Tools/Aids 

Naming  Convention 

A  naming  convention  was  established  and  used  for  all  CAMP  files.  The  primary  com¬ 
ponent  of  this  naming  convention  was  a  two-part  prefix  (i.e.,  xxx_yyy_).  The  first  part  of  the  prefix  (xxx) 
consisted  of  the  TLCSC  identification  number  (e.g.,  621  for  Basic_Dala_Types,  684  for  Geomelric_ 
Operations,  001  for  Common_Navigation).  This  part  of  the  prefix  was  used  on  all  files  (e.g.,  test  proce¬ 
dure,  lest  plan,  test  results)  pertaining  to  a  particular  TLCSC.  The  second  part  of  the  prefix  (yyy)  was 
used  to  indicate  level  of  nesting  of  the  part  contained  in  the  file  and  was  also  indicative  of  compilation 
order  for  that  TLCSC.  This  two-part  prefix  was  used  for  all  Ada  source  code  files  implementing  the 
TLCSCs. 

The  use  of  this  naming  convention  was  found  to  have  several  benefits.  It  simplified  the 
use  of  CMS.  For  example,  by  simply  specifying  "001*.*”,  a  list  of  all  baselined  files  dealing  with  the 
Common_Navigalion_Parts  TLCSC  could  be  obtained.  It  also  facilitated  the  development  of  tools  to  help 
with  the  compilation  of  parts.  This  naming  convention  has  now  been  adopted  by  several  other  Ada 
projects  within  McDonnell  Douglas. 

Code  Counter 

A  code  counter  was  developed  to  help  count  lines  of  code  and  documentation  for  each  of 
the  CAMP  parts.  The  code  counter  was  able  to  analyze  the  structure  of  an  Ada  source  code  file  and  break 
down  the  counts  among  the  individual  Ada  components  in  the  file.  For  example,  the  code  counter  could 
take  the  code  shown  in  Figure  9  and  tell  the  user  that: 

Coordinale_Vector_Matrix_Algebra  has  2  lines  of  code  and  4  lines  of  header  (not  including  items  nested  in  it) 

Vector_Operations  has  6  lines  of  code  and  4  lines  of  header  (not  including  items  nested  in  it) 

"+”  has  2  lines  of  code  and  0  lines  of  header 

has  2  lines  of  code  and  0  lines  of  header 

and  that: 

Coordinate_Vectnr_Mnlrix_Algebra  has  12  lines  of  code  and  R  lines  of  header  (including  items  nested  in  it) 

Veclor_Operalio»s  has  10  lines  of  code  and  4  lines  of  header  (including  items  nested  in  it) 

This  tool  has  proved  very  useful,  both  on  CAMP  and  other  projects. 
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--*TLCSC  NAME: 

— *  Coordin»t«_V«ctor_M*trix_Alg»br» 


p&ckag*  Coordinata_Vactor_Matrlx_Algabra  la 


— LLCSC  NAME: 

—  Vaator_Oparatlona 


ganaric 

typa  Elamant#  ia  digits  <>; 
typa  Indicaa  la  (<>) ; 
packaga  Vactor  Oparatlona  la 

typa  Vactera  la  array  (Indicaa)  of  Elaatanta; 

function  "+"  (Laft  :  Vactora; 

Right  :  Vactora)  ratum  Vactora; 

function  (Laft  :  Vactora; 

Right  :  Vactora)  ratum  Vactora; 

and  Vactor_Oparatlona; 

and  Coordlnata_Vaator_Matrix_Algabra; 


Figure  9.  Sample  Code  Counler  Input 


f.  Documentation 

All  CAMP  parts  arc  extensively  documented  for  the  following  reasons: 

•  External  users  of  the  parts  are  not  familiar  with  them  and  therefore  need  a  significant  amount  of 
information. 

•  The  CAMP  parts  make  extensive  use  of  generic  units,  and  most  users  are  relatively  unfamiliar  with 
the  advanced  features  of  generic  units.  A  sample  instantiation  is  included  in  the  code  headers  of 
generic  parts  which  shows  how  other  CAMP  parts  can  be  used  to  provide  the  required  generic 
actual  data  types,  objects,  and/or  subprograms.  In  some  cases,  the  sample  usage  section  shows  how 
the  generic  formal  parameters  can  be  used  to  tailor  the  part;  for  example,  how  to  tailor  a  matrix 
multiplication  routine  for  use  with  dynamically  sparse  matrices.  During  part  development,  this 
portion  of  the  documentation  was  time-consuming  to  produce  and  easily  affected  by  modifications 
to  the  part.  Later,  however,  it  turned  out  to  be  one  of  the  more  useful  pieces  of  documentation  for 
the  engineers  developing  the  1 1th  Missile  Application  since  they  were  unfamiliar  with  the  use  of 
the  part. 

A  Software  Development  File  (SDF)  was  prepared  for  all  CAMP  TLCSCs.  Table  4  shows  the 
sections  contained  in  each  SDF,  along  with  the  information  that  was  maintained  in  each  section. 

All  of  tile  documentatio  i  on  a  part  is  contained  in  its  lop-level  and  detailed  design  headers.  A 
software  tool  (see  Section  II.2.e.(4))  was  developed  to  extract  information  from  appropriate  sections  of 
the  headers  for  placement  in  the  design  documents.  Figures  10  and  1 1  identify  the  information  contained 
in  the  CAMP  top-level  and  detailed  design  headers,  and  indicate  which  of  these  sections  are  extracted  for 
use  in  the  top-level  or  detailed  design  documents. 
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TABLE  4.  SOFTWARE  DEVELOPMENT  FILE  CONTENTS 


SECTION 

CONTENTS 

Requirements 

Requirements  for  this  part 

Top-level  design 

Package  specification  for  the  TLCSC 

Detailed  design 

Body  for  Hie  TLCSC 

Test  plan/procedure 

Test  procedurc/plan  for  the  TLCSC,  along  with  the  test  code 

Test  results 

Latest  set  of  test  results 

Problem  reports  and 
log 

Software  discrepancy  reports  (SDRs)  for  this  TLCSC,  along  with 
disposition 

Change  orders  and 
log 

Software  enhancement  proposal/software  change  proposal  forms 
(SEP/SCP).  along  with  disposition 

Miscellaneous 

Walkthrough  records  * 

EXTRACTED  FOR 

HEADER  CO.’  TENT  S 

DLSlON  DOCUMENT 

Name 

• 

Identification  Number 

• 

Security  Level 

Purpose 

♦ 

Requirements  trace 

• 

Contest 

* 

Utilization  of  external  elements 

Packages 

• 

Subprograms  and  task  entries 

• 

Exceptions 

• 

Data  types 

• 

Data  objects 

• 

Input/output 

Generic  parameters 

Data  types 

• 

Data  objec  ts 

• 

Subprograms 

• 

Formal  parameters 

Exported  exceptions/typcs/ohjects 

Exceptions 

• 

Data  types 

• 

Data  objects 

• 

Exceptions  raised 

• 

Calling  sequence/timing/priority 

• 

Interrupt  handling 

• 

Sample  usage 

• 

Decomposition 

• 

Local  entities  contained  in  package  body 

• 

Figure  10.  Top-Level  Design  Header  Information 


The  main  benefit  of  using  code  design  headers  to  produce  design  documents  is  that  only  one  set 
of  documentation  needs  to  be  maintained.  This  allows  a  part  to  be  modified  without  also  modifying 
documents  immediately  or  trying  to  remember  at  a  later  date  which  sections  of  the  document  need  to  be 
updated.  When  it  is  time  to  produce  an  updated  document,  the  text  merely  has  to  be  re-extracted.  This 
allows  time  to  produce  extensive,  high-quality  documentation  by  eliminating  tedious  and  often  error- 
ridden  duplication. 
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EXTRACTED  FOR 

HEADER  CONTENTS 

DESIGN  DOCUMENT 

Name 

• 

Idenlifk  ation  Number 

• 

.Security  l/’vel 

Purpose 

* 

Requirements  trace 

* 

Context 

* 

l  Milization  of  external  elements 

Packages 

* 

Subprograms  and  task  entries 

* 

Exceptions 

* 

Data  types 

* 

Data  objects 

* 

Utilization  of  other  elements  in  top-level  component 

* 

Packages 

• 

Subprograms  and  task  entries 

* 

Exceptions 

• 

Data  types 

* 

Data  objects 

* 

Inpul/output 

Generic  parameters 

Data  types 

* 

Data  objects 

* 

Subprograms 

* 

Formal  parameters 

* 

Focal  exceptions/types/objects 

Exceptions 

* 

Data  types 

* 

Data  objects 

• 

Focal  entities 

* 

Exceptions  raised 

* 

Galling  sequence 

• 

Figure  II.  Detailed  Design  Header  Information 


.3.  CAMP  PARTS  PROCESS  ANALYSIS 

In  order  to  assess  productivity  for  parts  development  on  the  CAMP  project,  effort  data  was  collected 
from  all  members  of  the  CAMP  team  in  the  areas  of  domain  and  requirements  analysis,  architectural 
design,  detailed  design,  coding,  testing,  etc.  This  was  then  combined  with  sizing  data  to  determine 
productivity.  Productivity  figures  can  be  misleading,  and  sometimes  impossible  to  compare  because  of 
the  many  ways  they  can  be  calculated.  Productivity  is  generally  quoted  in  terms  of  lines  of  code  per 
man-month,  but  authors  frequently  don't  define  terms  or  specify  what  is  included  in  code  counts. 

The  size  of  the  CAMP  parts  was  determined  using  two  metrics:  lines  of  code  and  Ada  statements.  A 
line  of  code  was  defined  as  any  line  in  the  source  code  file  which  contained  all  or  part  of  an  Ada 
statement.  If  a  single  Ada  statement  occupied  three  lines  in  the  source  code  file,  then  it  was  counted  as 
three  lines  of  code.  A  statement  count,  on  the  other  hand,  counted  whole  Ada  statements:  in  effect 
counting  semicolons.  The  difference  between  these  two  methods  of  determining  code  size  is  illustrated  in 
Figure  12 

The  total  si/c  of  the  CAMP  parts,  in  units  ol  lines  of  code  and  Ada  statements,  is  shown  in  Figure 
1 3.  As  shown  in  this  figure,  over  43.000  lines  of  Ada  code  were  developed  during  CAMP;  this  included 
over  16,000  lines  of  code  for  the  parts  themselves  and  over  27,500  lines  of  test  code.  Using  Ada  stale- 
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package  Ganaral_Vactor_Matrix__Algabra  it 
ganarlc 

typa  Laft_El an\an ts  is  digits  <>; 

typa  Right__Elamants  is  digits  <>; 

typa  Output  JElamantt  is  digits  <>; 

typa  Laft_Col_Indicas  is  (<>) ; 

typa  Laft_Row_Indicas  is  (<>)  ; 

typa  Right__Col_Indicaa  is  (<>) ; 

typa  Right_Row_Indicas  is  (<>)  ; 

typa  Output_Col_Indicas  is  (<>) ; 

typa  Output_Row_Indicat  is  {<>)  ; 

typa  Laft_Matricas  is  array  (Laft_Row_Indicaa, 

Laft_CoX_Indicas)  of  Laft_Elamanta ; 
typa  Right_Matricas  is  array  (Right_Row_Indlcaa, 

Right_ Col_Indioas ) 
of  Right_EXamants; 

typa  Output_Matricas  is  array  (Output_Row_Indioat , 

Output_Col_Indicaa ) 
of  Output_Elamanta; 

with  function  (Laft  :  Laft_Elamants; 

Right  :  Right_Elamant • ) 
raturn  Output_Elamanta  is  <>; 
packaga  Matrix_Matrix_Tranapoaa_Multiply_J7nraatrictad  is 

function  (Laft  :  Laf tJMatricaa ; 

Right  :  Right_Hatricas)  raturn  Output_Matricas; 

and  Hatrix__Hatrix^_Transposa__Multiply__Unrastrictad; 

and  Ganaral_Vactor_Matrix_Algabra; 


Counting  the  above  code,  using  lines  of  code  and  Ada  statements  as  the  metrics,  yields  the 
following  results: 

Lines  of  Code  Ada  Statements 

27  16 


Figure  12.  Lines  of  Code  versus  Ada  Statements 


ments  as  the  sizing  metric,  over  28,000  Ada  statements  were  developed  during  CAMP  with  over  10,000 
of  these  being  part  code  and  almost  18,000  being  test  code. 


S  X  ZE 


LINES  OF 
ADA  CODE 

ADA 

STATEMENTS 

LINES  OF 
COMMENTS 

PART  CODE 

16,091 

10,203 

91,553 

TEST  CODE 

27,584 

17,991 

TOTAL 

43,675 

28,194 

Figure  13.  CAMP  Parts  Sizing  Data 
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On  any  software  project,  source  code  must  be  developed  and  documented.  Section  II.2.f  discusses 
(he  vital  role  extensive  documentation  plays  in  the  successful  use  of  reusable  software.  This  is  reflected 
in  the  sizing  data  contained  in  Figure  13  which  shows  that  the  ratio  of  lines  of  comments  to  lines  of  code 
is  approximately  3.7:1  and  the  ratio  of  lines  of  comments  to  Ada  statements  is  almost  9:1. 

Code  size  is  not  the  only  factor  in  determining  productivity;  effort  must  also  be  assessed.  Effort  data 
for  development  of  the  CAMP  parts  is  shown  in  Figure  14.  It  includes  the  number  of  hours  expended  for 
all  phases  of  the  CAMP  parts  life  cycle,  from  domain  analysis  through  maintenance.  A  total  of  9734 
man-hours  of  effort  went  towards  (he  development  of  the  CAMP  parts,  with  6557  of  these  hours  ex¬ 
pended  during  the  design  and  testing  phases. 


The  productivity  statistics  for  development  of  the  CAMP  parts,  using  several  metrics,  is  shown  in 
Figure  15.  The  importance  of  knowing  how  productivity  is  being  measured  can  be  seen  in  this  figure 
which  shows  that  productivity  figures  from  164  statements/man-month  to  1039  lines  of  code/man-month 
can  be  justified,  depending  on  how  and  what  code  is  counted  and  what  is  included  in  the  man-month 
figures. 

Figure  16  gives  an  overall  picture  of  the  development  statistics  for  the  CAMP  parts  development 
effort.  The  data  includes  the  most  conservative  numbers  shown  in  Figure  15,  using  code  counts  for  parts 
code  only  and  man-month  figures  for  the  entire  CAMP  effort.  It  can  be  seen  from  this  figure  that  the 
productivity  experienced  during  CAMP  parts  development  was  approximately  61%  greater  than  that 
predicted  by  COCOMO  for  embedded  software  development.  Several  factors  contributed  to  this  in¬ 
creased  productivity: 

•  Ada:  The  Ada  language  itself  contributes  to  increased  productivity.  Strong  data  typing,  for  ex¬ 
ample,  helps  to  ensure  that  many  errors  are  found  during  compilation  rather  than  being  found 
during  testing  when  they  would  he  more  time  consuming  and  costly  to  correct. 

•  Good  people:  All  members  of  the  CAMP  parts  development  team  had  at  least  some  Ada  ex¬ 
perience  prior  to  joining  the  project,  and  all  received  training  in  software  engineering  practices 
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Figure  15.  CAMP  Paris  Productivity  Data 


SIZE 

PRODUCTIVITY 

EXPECTED 

PRODUCTIVITY 

(COCOMO) 

DELTA 


Figure  16.  CAMP  Parts  Development  Statistics 


either  before  or  after  joining  the  project.  In  addition,  several  members  of  the  team  had  extensive 
Ada  experience  and  were  available  to  help  train  new  people.  There  was  also  continuity  of  person¬ 
nel  between  CAMP- 1  and  CAMP-2,  with  key  members  of  the  CAMP-1  team  remaining  throughout 
CAMP-2.  This  provided  increased  consistency  in  the  overall  design  philosophy  of  the  parts  and 
increased  the  ability  to  pass  on  the  lessons  learned  during  earlier  phases  of  development. 

*  Good  tools:  As  discussed  in  Section  Il.2.e,  various  tools  were  used  throughout  the  CAMP 
program;  they  made  a  significant  contribution  to  increased  productivity. 
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•  Code  reuse:  During  CAMP,  not  only  was  reusable  code  developed,  but  it  was  used  in  the  develop¬ 
ment  of  more  reusable  code.  It  was  often  possible  to  use  previously  developed  specifications 
and/or  bodies  to  create  new  reusable  parts.  A  simple  example  of  this  involves  matrix  addition  and 
subtraction  routines.  Since  the  differences  between  the  two  are  minor,  the  matrix  addition  routine 
can  be  developed  and  completely  documented,  and  then  the  subtraction  routine  can  be  created 
simply  by  copying  and  making  minor  modifications  to  the  addition  routine. 
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SECTION  III 


INTER-RELATIONSHIPS  BETWEEN  CAMP  PARTS 

An  important  aspect  of  the  design  of  the  CAMP  parts  is  the  way  various  parts  were  designed  to  build 
on  other  parts,  work  together,  and  facilitate  using  other  parts.  These  relationships  between  the  parts  are 
further  discussed  in  the  following  paragraphs.  Figure  17  shows  how  these  relationships  come  into  play 
when  developing  a  small  portion  of  a  navigation  system. 

I.  PARTS  BUILD  ON  OTHER  PARTS 

One  example  of  parts  building  on  other  parts  involves  the  Polynomials,  Standard_Trig,  and  Basic_ 
Data_Types  TLCSCs  as  illustrated  in  Figure  18.  The  Polynomials  TLCSC  lies  at  the  bottom  of  the  build 
and  provides  an  extensive  set  of  polynomial  solutions  to  various  transcendental  functions.  The  generic 
Standard_Trig  TLCSC  forms  the  second  layer  by  exporting  trigonometric  data  types  and  operations. 
Standard_Trig  uses  the  Polynomials  package  to  obtain  the  required  polynomial  solutions  to  its  exported 
transcendental  functions.  The  Basic_Data_Types  TLCSC  provides  the  final  layer.  In  addition  to  provid¬ 
ing  a  set  of  data  types  and  operations  typical  of  a  navigation  implementation,  Basic_Data_Types  instan¬ 
tiates  the  Slandard_Trig  package.  This  design  approach  offers  several  advantages: 

•  Minimal  functionality  is  added  from  one  step  to  the  next. 

•  Users  of  the  higher  level  packages,  such  as  Basic_Data_Types,  frequently  will  not  need  to  reference 

the  lower  level  packages,  such  as  Polynomials. 

•  Finally,  combining  the  parts  saves  work  for  the  user. 

In  this  example,  a  user  merely  needs  to  import  Basic_Data_Types  in  order  to  obtain  a  full  set  of 
navigation  data  types  (such  as  various  forms  of  distances,  velocities,  accelerations,  etc.),  operators  upon 
these  types,  trigonometric  data  types  (such  as  radians,  degrees,  etc.),  and  a  full  set  of  trigonometric  func¬ 
tions. 
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ConvFaetors 


USER  APPLICATION  PROGRAM 

pkg  VeISqRt  Is  new  GPMathSquareRoot ... 
pkg  AngVeISqRt  Is  new  GPMath.Squafe_Root ... 
pkg  AeeeISqRt  Is  new  GPMath.Square_Root ... 
pkg  DIstSqRt  Is  new  GpMath.Square_Root ... 


pkg  VelVOpns 
pkg  AngVelVopns 
pkg  AccelVOpns 
pkg  DlstVOpns 


Is  new  CVMA.Vector  Opns ... 
Is  new  CVMA.Vector_Opns  ... 
Is  new  CVMA.Vector_Opne  ... 
Is  new  CVMA  Vector  Opn* ... 


In  CrossProd  AW  VV  Is  new  CVMA.Cros*  Product . 


In  CorAccel  Is  new  NPNav.Compute_Corlolls_Acceleratlon 
pkg  RadOfCurvIs  new  NPNav.Radlus_of_Curvature  ... 
pkg  Latin!  Is  new  NPNav.LatltudeJntegratlon  ... 


I  A  total  of  Id  packages  must  be  compiled  into  the  user's  library.  The  user  himself  requires  six  of  these  (indicated  by  arrows  into 
(he  user  application):  the  six  packages  require  an  additional  four. 

2.  The  user  must  do  (he  following  before  instantiating  the  navigation  parts: 

•  Instantiate  four  versions  of  the  square  root  package  (OPMath.Square_Root)  using  data  types  and  operators  supplied  by 

tlie  basic  data  types  (BUT)  package. 

•  Instantiate  four  versions  of  the  vector  operations  package  (CVMA.Veclor_Opns)  using  data  types  and  operators 

supplied  by  BDT  and  the  square  root  functions  contained  in  the  packages  previously  instantiated  by  the  user. 

•  Instantiate  a  cross  product  function  using  scalar  data  types  and  operations  supplied  by  BDT,  along  with  vector  data 

types  and  operations  obtained  from  three  separate  instantiations  of  CVMA.Vector_Opn! 

.!.  Tltc  three  navigation  parts  can  then  be  instantiated  using: 

•  Scalar  data  types  and  operators  supplied  by  BDT. 

•  Scalar  data  types  and  trigonometric  functions  supplied  by  an  instantiation  of  the  standard  trig  package  contained  in  BDT 

(HDT.Trig). 

•  Vector  ty  pes  and  operations  supplied  by  the  four  instantiations  of  CVMA.Vector_Opns. 

•  Data  constants  supplied  by  the  WOS72  ellipsoid  metric  data  pockage  (WOS72)  and  the  WGS72  ellipsoid  unitless  data 

package  (WC!S72t!l. 

•  I  tser-defined  data  types  and  objects. 

Figure  17.  Assembling  a  Nortli-Poinling  Navigation  System 
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2.  PARTS  WORK  TOGETHER 

Parts  were  also  designed  to  work  together,  using  low-level  parts  to  support  more  complex  operations. 
This  design  approach  differs  from  the  approach  previously  discussed  in  that  functionality  is  added  with 
each  step  and  the  lower  TLCSCs  are  frequently  required  by  the  user.  An  example  of  this  interrelationship 
can  be  seen  in  the  Geometric_Operations  and  Waypoint_Sleering  TLCSCs  shown  in  Figure  19.  The 
Waypoint_Steering  TLCSC  exports  the  Steering_Vector_Operations  package  which  handles  the  in¬ 
itialization  and  updating  of  waypoint  steering  vectors.  In  order  to  perform  its  operations,  the  Steering_ 
Vector_Operations  package  instantiates  two  subroutines  from  the  Geometric_Operations  package  which 
are  designed  to  calculate  unit  radial  vectors,  unit  normal  vectors,  and  course  segments.  This  design 
methodology  has  several  benefits: 

•  Since  the  geometric  operations  are  not  placed  in  the  package  body  of  the  Waypoint_Steering 
TLCSC,  they  are  also  available  to  the  user. 

•  Not  duplicating  the  Oeometric_Opcrations  code  within  the  Waypoinl_Steering  TLCSC  improves 
maintainability. 

•  Performing  the  instantiations  of  the  Gcomctric_Opcrations  parts  within  the  Steering_Vector_ 
Operations  LLCSC  instead  of  bringing  them  in  as  generic  subroutines  saves  the  user  the  work  of 
finding  the  additional  parts  and  doing  the  instantiations. 
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3.  CAMP  PAR  I  S  FACILITATE  USE  OF  OTHER  PARTS 

Finally,  parts  were  designed  to  facilitate  using  other  parts  by  providing  the  requisite  generic  actual 
parameters.  An  example  of  this  is  shown  in  Figure  20.  In  order  to  instantiate  the  generic  Compute. 
Segmcnt.and.Unit.Normal.Vector  procedure,  the  only  data  type  the  user  needs  to  define  is  a  discrete 
type  for  Indices.  The  remaining  scalar  types  can  be  obtained  from  the  Basic_Data_Types  package,  along 
with  the  multiplication  and  division  operators;  the  vector  type  and  operations  on  that  type  (i.e..  Vector. 
Length  and  Cross.Product)  can  be  obtained  by  instantiating  the  Vector.Operations  package  in  the 
Coordinate.Vector.Matrix.Algebra  'TT.CSC;  and  a  value  for  the  radius  of  the  Earth  can  be  found  in  the 
WGS72_Ellipsoid_Engincering_Data  TLCSC.  This  kind  of  support  can  be  found  in  most  of  the  CAMP 
parts. 
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Figure  20.  CAMP  Paris  Facilitate  Use  of  Other  Parts 

When  designing  the  CAMP  parts,  a  primary  consideration  was  how  to  provide  low-level  operations, 
such  as  linear  algebra  and  transcendental  functions,  to  the  more  complex  routines.  There  were  several 
options: 

1 .  In-line  the  required  operations  directly  into  the  higher  level  routine:  This  option  was  considered 
unacceptable  since  it  would  have  caused  the  parts  to  become  excessively  large.  Also,  in-lining 
would  have  increased  testing  time  and  brought  about  the  potential  for  a  maintenance  nightmare. 

2.  Place  the  required  code  in  subroutines  located  in  package  bodies:  This  option,  while  an  improve¬ 
ment  over  option  1 ,  would  also  increase  the  size  of  the  parts,  lengthen  testing  lime,  and  increase 
maintenance  difficulties. 

3.  Instantiate  a  required  operation  from  another  CAMP  part.  In  a  few  cases,  this  option  was  chosen. 
This  method  was  considered  desirable  if:  1 )  only  one  method  existed  for  implementing  the  re¬ 
quired  operation;  or  2)  the  instantiating  part  were  a  very  high-levei  part,  such  as  a  Kalman  update 
package,  designed  to  provide  one  possible  solution  to  a  problem  by  bringing  together  one  possible 
comoination  of  lower  level  parts. 

This  option  was  not  considered  acceptable  if  the  required  operation  was  a  very  basic  one,  such  as  a 
trigonometric  function,  and  there  was  no  way  of  knowing  ahead  of  time  which  algorithm  would 
provide  optimal  performance. 

4.  Bring  in  the  required  operations  via  generic  parameters:  This  option  was  chosen  in  the  vast 
majority  of  cases. 

The  use  of  generic  formal  subprograms  to  import  required  operations  is  an  important  design  feature 
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of  the  parts.  It  has  the  advantage  of  providing  great  flexibility  to  the  user  by  providing  CAMP  parts  to 
supply  low  level  operations  or  allowing  the  user  to  define  his  own,  as  shown  in  the  following  examples. 


* 
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•  Example  1 

In  this  example,  assume  the  user  wishes  to  instantiate  both  of  the  parts  contained  in  the  Geomelric_ 
Operations  TLCSC  shown  in  Figure  21.  Each  part  requires  a  sine/cosine  procedure  as  a  generic 
parameter.  If  (he  user  has  imported  the  Basic_Data_Types  (BDT)  package,  he  already  has  access  to 
the  sine/cosine  procedure  provided  indirectly  cy  BDT’s  instantiation  of  Slandard_Trig  (Trig).  If 
this  procedure  is  satisfactory  for  his  computations,  the  user  need  not  specify  it  in  his  instantiation 
since  the  BDT  version  will  be  selected  by  default.  If.  however,  the  user  feels  his  calculations 
require  more  accuracy  or  speed,  he  may  construct  a  different  sine/cosine  procedure  by  building  one 
from  the  over  25  sine  functions  provided  by  the  Polynomials  TLCSC  or  by  writing  his  own.  This 
new  sine/cosine  procedure  may  then  be  used  in  one  of  the  following  ways: 

•  If  he  wishes  to  use  this  new  procedure  throughout  his  application  for  all  sine/cosine  calcula¬ 
tions,  the  procedure  can  be  specified  in  such  a  way  as  to  hide  the  sine  function  contained  in 
BDT.Trig.  He  can  then  let  the  generic  actual  subroutines  default  to  this  new  procedure.  This 
is  illustrated  in  Figure  22. 

-  If  the  newly  created  sine/cosine  procedure  is  to  be  used  only  for  certain  calculations,  it  can  be 
designed  in  such  a  way  as  to  not  hide  the  one  contained  in  BDT.Trig.  In  this  case,  the  special 
procedure  would  have  to  be  explicitly  specified  in  instantiations  where  it  was  to  be  used. 
Using  this  method,  it  is  possible  for  the  user  to  create  multiple  sine/cosine  procedures  —  a 
fast  one,  a  highly  accurate  one,  mid  a  general  purpose  one  —  to  meet  his  needs.  This  is 
illustrated  in  Figure  23. 


package  Geometric_Operation»  la 


generic 

type  Angle  la  digits  <>: 
type  Trig.Ratio  Is  digits  <>: 
package  Standard_Trig  Is 

type  Radians  Is  new  Angle: 

type  Sin_Cos_Ratio  Is  new  Trig_Ratio  range  - 1 .0..  1 ,0: 

procedure  Sin_Cos  (Input  :  In  Radians: 

Sin_Resul!  :  out  Sin_Cos_Ratio; 

Cos_Resull  :  out  Sin_Cos_Ralio); 

end  Standard_Trig; 


with  SYSTEM: 
with  StandardTrig: 
package  Basic_Dala_Types  is 

type  Real  Is  digits  S  YSTEM.MAX_DIOn  S: 
type  Meters  Is  digits  SYSTEM.MAX_DIGtTS: 

package  Trig  Is  new  Standard_Trig 

(Angle  ->  Real, 
Trig_Ratio  =>  Real); 

type  Earlli_Posilion_Radians  Is  new  Trig. Radians: 

function  (Left  :  Meters: 

Right  :  Trig.Sin_Cos_Ratio) 
return  Meters; 

end  Basic  Datatypes; 


generic 


type  Indices 

to  (<>): 

type  Earth_Positions  to  digits  <>; 
type  Sin_Cos_Ratio  to  digits  <>: 

type  Unit_Vectors 

to  array  (Indices) 

of  Sin_Cos_Ratio; 

X :  In  Indices 

:*  Indices'FIRST; 

Y  :  In  Indices 

:=  Indices ’SUCC(X): 

Z  :  In  Indices 

:*=  tndices’LAST; 

with  procedure  Sin_Cos 

(Input  :  In  Earth_Po*itionti; 

Sine  oat  Sin_Cos_R*tio; 

Cosine  oat  Sin_Cos_R*tio) 

b  <>; 

function  Unit_Radial_Vector 

(Lat_of_Point  :  Earth_Po»itiona: 

Long_of_Point  :  Earth_Positions) 
return  Unit_Vecton; 

generic 

type  Earth.Distances  to  digits  <>; 

type  Earth_Positiona  to  digits  <>; 

type  Segment_Distances  to  digits  <>; 

type  Sin_Cos_Ratio  to  digits  <>; 

Earth_Radius  :  In  Earth_Distances: 

with  function  (Left  :  Earth_Distances; 

Right  :  Sin_Cos _R«tio) 
return  Segnwnt_Distances  la  <>: 
with  function  Sqrt  (Input :  Sin_Coa_Ratio) 

return  Sin_Coa_Ratlo  la  <>: 
with  procedure  Sin_Cos 

(Input  :  In  Earth_Poailiona: 
Sine  out  Sin_Co«_Ratio; 

Cosine  out  Sin_Cos_R<‘io) 

to  <>: 

package  Oreat_Circle_Arc_Length  Is 

function  Compute 

(Lalitude_A  :  Earth_Posilions: 
Latitude_B  :  Ear1h_Poailions: 
Longitude_A  :  Earth_Positions; 
Longitude_B  :  Earth_Posllions) 
return  Segment_DisUnces; 

end  C  ircal_(  irc  !c  Arc  l  ength: 

end  (ieometric_Opsrations: 


Figure  21.  Required  Operations  Obtained  Through  Use  of  Generic  Formal  Parameters 
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with  Basic_Data_Types 
with  Oeometric_Operaliotis: 
with  WQS72_Ellipsoid_Melric_Dala: 
procedure  User_Applkation  Is 

use  Basic_Data_Types; 

package  BDT  renames  Basic_Data_Types: 

package  GEO  renames  Geometric_Operations: 

package  WGS72  renames  WGS72_Ellipsoid_Melric_Dala: 

type  Indices  Is  (X,  Y,  Z): 

type  Unit_Vectors  Is  array  (Indices)  of  BDT. Trig. Sin_Cos_Ratio: 

function  Sqrt  (Input  :  HDT.Trig.Sin_Cos_Ratio) 
return  BDT.Trig. Sin_Cos_Ralio: 

--  —new  Sin  Cos  procedure  to  override  that  provided  hy  BDT.Trig 
procedure  Sin_Cos  (Input  :  In  BDT.Earth_Position_R»dians; 

Sine  out  BDT.Trig, Sin_Cos_Ralio; 

Cosine:  out  BDT.Trig.Sin_Cos_Ralio); 

function  U_Radial_Vector  Is  new  GEO.Unit_Radial_Vector 

(Indices  =>  Indices, 

Earth_Positions  =>  BDT.Earth_Position_Radians, 

Sin_('ns_Ratio  =>  BDT.Trig. Sin_Cos_Ratlo, 

Uni(_Vec(orri  =>  Unit_Vectors); 

-•  —Sin  Cos  defaults  to  new  Sin  Cos  procedure 

package  Great  (.ire  le  Arc  len  is  new  GEO  Qreat_Circle_Arc_Length 

(Earthy Distances  =>  BDT.Meiens, 

Earth_Positions  *>  BDT.Earth_Position_Radians, 

Segmenl_DislaiKCs  ■>  BDT.Meters, 

Earth_Radius  «>  WGS72.Earlh_Equatorial_Radius, 

Sin_Cos_Ralio  *=>  BDT.Trig.Sin_Cos_R»tin): 

—  Sin_Cos  defaults  to  nc tv  SinjCos  procedure 

begin 

end  User_Application; 


Figure  22.  Sample  Instantiations  of  Geometric_Operations  Parts 

Using  Default  Routines 


with  Baaic_Dnla_Types: 
with  Oeome(ric_Opera(ions: 
with  WGS72_Ellipsoid_Metric_Dala; 
procedure  User_Applic«tion  b 

use  8asic_Dala_Types; 

package  DDT  renames  Basic_Data_Types: 

package  GEO  renames  Geomctric_Operations: 
package  WGS72  renames  WGS72_Ellipsoid_Metric_Dala; 

type  Indices  Is  (X,  Y,  7.): 

type  Unii_Veclors  Is  array  (Indices)  of  BDT.Tiig.Sin_Co*_Raiio: 

function  Sqrt  (Input :  BDT.Trig.Sin_Cos_Ratio) 
return  BDT.Trig.Sin_Cos_Ratio: 

—  -additional  Sin  Cos  procedure 

procedure  Fast_Sin_Cos  (Input  :  In  BDT.Earth_Posilion_Radiana: 

Sine  out  BDT.Trig.Sin_Cos_Ratio: 

Cosine:  out  BDT.Trig.Sin_Cos_Ralio): 

function  U_Radial_Vector  Is  new  GEO.Unit_Radial_Vec(or 

(Indices  =>  Indices, 

Earth_Positions  =>  BDT.Earth_Posiiion_Radians, 

Sin_Cos_Ratio  BDT.Trig.Sin_Cos_Ratio, 
Unit_Veclors  =>  Unit_Vectors, 

Sin_Cos  «>  Fast_Sin_Cos); 


package  Oreat_Circle_Arc_Len  b  new  GEO.Oreal_Circle_Arc_Lengtli 

(Earth_Dis  lances 
Earlh_Positions 
Segment_Disiances 
Earth_Radius 
Sin_Cos_Ralio 


-  -SinCos  defaults  to  BM  Trig.Sin  Cos 


■>  BDT.Meters, 

>  BDT.Earth_Position_Radians, 

>>  BDT.Meten, 

i>  WGS72.Earth_Equatorial_Radius, 
•>  BDT.Trig.Sin_Cos_Ratio): 


begin 

end  User_Applica(ion: 


Figure  23.  Sample  Instantiations  of  Geometric_Operations  Parts 
Using  Specialized  Sin_Cos  Procedure 
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Example  II 


In  this  example,  the  user  wishes  to  construct  a  Kalman  filter  using  a  complicaled-H  matrix.  If  he 
uses  the  Kalman_Filter_Data_Types  package  and  all  the  data  types  it  provides,  all  generic  formal 
subroutines  required  by  instantiations  of  any  of  the  parts  contained  in  the  Kalman_Filler_Common_ 
Parts  and  Kalman_Filter_Complicated_H_Part  TLCSCs  will  properly  default.  If  however,  he 
wishes  to  use  reduced  storage  rather  than  full  storage  matrices,  it  is  possible  for  him  to  define  his 
own  data  types  and  operations  and  still  use  the  Kalman  filter  parts  without  making  any  modifica¬ 
tions  to  the  parts  themselves.  This  latter  option  is  the  one  that  was  chosen  for  the  11th  Missile 
Application. 
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SECTION  IV 


DEVELOPMENT  AND  TESTING 
OF  A 

PARTS  COMPOSITION  SYSTEM  (PCS) 

The  major  problems  associated  with  software  reuse  efforts  have  been  the  lack  of  information  on  the 
availability  and  applicability  of  reusable  parts  and  the  lack  of  information  on  how  to  use  those  pans. 
During  (he  CAMP- 1  feasibility  study,  it  was  concluded  that  software  reuse  would  not  come  to  fruition  if 
there  were  not  some  mechanism  for  assisting  the  potential  user  in  identifying,  locating,  and  using  avail¬ 
able  software  parts.  One  such  mechanism  is  a  parts  composition  system  (PCS)  which  can  facilitate  the 
use  of  existing  software  parts  by  providing  tools  to  perform  some  of  the  mechanical  tasks  associated  with 
software  reuse. 

The  objective  of  the  CAMP-1  feasibility  study,  with  respect  to  parts  composition  systems,  was  to 
determine  the  feasibility  and  value  of  automating  some,  or  all,  of  the  process  of  using  and  managing 
software  parts.  The  study  involved  an  investigation  of  both  short  and  long-term  possibilities.  Feasibility 
was  clearly  established  (Reference  7),  and  (he  requirements  and  top-level  design  of  a  parts  composition 
system  were  specified  during  CAMP-1. 

During  CAMP-2,  a  prototype  parts  composition  system  was  implemented  and  tested,  and  then  used 
by  the  11th  Missile  development  team  to  demonstrate  its  utility  and  value.  This  prototype,  which  is 
referred  to  as  the  Ada  Missile  Parts  Engineering  Expert  (AMPEE)  system,  alleviates  many  of  the 
problems  associated  with  software  reuse  by  providing  the  user  with  an  expert  assistant  to  advise  him  on 
the  availability  and  relevance  of  CAMP  reusable  Ada  software  parts  to  his  application,  and  to  aid  in  the 
development  of  software  systems  by  automatically  generating  the  required  code  for  particular  operations 
or  subsystems  of  the  application,  c.g.,  navigation,  Kalman  filler,  or  autopilot  operations. 

I.  PCS  FUNCTIONALITY 

Although  much  of  the  AMPEE  system  is  CAMP-specific.  the  underlying  principles  are  applicable  to 
a  variety  of  domains.  The  AMPEE  system  established  the  functions  required  of  a  parts  composition 
system  to  assist  the  user  in  using  reusable  software  parts. 

A  three-pronged  approach  was  taken  in  assisting  the  user  with  the  reusable  CAMP  software  parts. 
This  approach  is  embodied  in  the  three  major  subsystems  of  the  AMPEE  system  —  Parts  Catalog,  Parts 
Identification,  and  Component  Construction.  The  Parts  Catalog  subsystem  is  similar  to  an  automated 
card  catalog  for  books,  i.e.,  it  is  used  to  locate  reusable  software  parts  and  obtain  information  about  those 
parts.  This  subsystem  also  provides  a  means  to  maintain  the  catalog  in  an  up-to-date  form.  The  Parts 
Identification  subsystem  provides  the  user  with  access  to  the  on-line  parts  catalog  at  a  very  high  level. 
Unlike  the  Parts  Catalog  subsystem  which  requires  the  user  to  have  some  idea  of  the  types  of  parts  that  he 
is  looking  for.  the  Parts  Identification  subsystem  provides  the  user  with  access  to  the  information  in  the 
catalog  based  solely  on  his  knowledge  of  his  own  application,  i.e.,  before  he  knows  about  specific  parts. 
The  Component  Construction  subsystem  provides  the  user  w  ith  a  means  of  generating  tailored  Ada  com- 
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ponents  based  on  reusable  meta-parts  that  are  in  the  Parts  Catalog.  Meta-parts  were  described  in  the 
CAMP-1  Final  Technical  Report  7,  and  are  discussed  further  in  Section  IV.l.c.  Each  of  these  subsys¬ 
tems  is  discussed  in  greater  detail  in  the  following  paragraphs. 


n.  Pails  Catalog 

The  backbone  of  the  AMPEE  system  is  a  software  parts  catalog  for  the  CAMP  reusable  Ada 
missile  software  parts.  Earlier  research  (during  the  CAMP  feasibility  study)  indicated  that  a  major  limit¬ 
ing  factor  in  the  widespread  acceptance  and  use  of  off-the-shelf  software  was  the  lack  of  reliable  infor¬ 
mation  describing  the  parts  in  adequate  detail  to  determine  their  applicability  to  a  particular  software 
project.  Under  the  CAMP  project,  a  catalog  was  developed  that  provides  the  type  of  information  that  is 
needed  to  make  informed  decisions  about  parts.  Each  reusable  software  part  is  described  by  numerous 
attributes;  these  are  enumerated  in  Figure  24,  and  described  in  detail  in  Appendix  B. 


GENERAL 

Pari  Number 

Revision  Number 

Part  Name 

Functional  Abstract 

Mode 

Toxononictric  Category 

Class 

Keywords 

Lost  Change  Date  of  Entry 

Project  Usage 

Government  Security  Classification  (pari) 

Corporate  Sensitivity  Ijevel  (part) 

Government  Security  Classification  (entry) 

Corporate  Sensitivity  Level  (entry) 

Remarks 

DEVELOPMENT 

Design  Issues 

Revision  Notes 

Development  Date 

Developer 

Development  Status 

Developed  For 

Requirements  Documentation 

Design  Documentation 

USAGE 

Location  of  Source  Code 

Access  Notes 

With* 

Wilhed  By 

Implemented  By 

Implements 

Built  From 

Used  to  Build 

Sample  Usage 

Hardware  Dependencies 

Restrictions 

PERFORMANCE 

Source  Size/Complexity  Characterizations 

Fixed  Object  Code  Size 

Timing 

Accuracy 

Figure  24.  Catalog  Attributes 


It  is  important  to  distinguish  between  the  CAMP  parts  themselves  and  the  software  entities  that 
are  cataloged.  Parts  were  defined  in  Section  II.  I .  There  is  not  a  one-to-one  correspondence  between 
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CAMP  parts  and  catalog  entries.  Although  parts  are  cataloged,  Ada  package  bodies  are  cataloged 
separately  from  their  specifications;  encapsulating  packages  are  also  cataloged.  Thus,  although  ap¬ 
proximately  450  CAMP  Ada  parts  have  been  implemented  and  tested  to  date,  there  are  over  1 100  catalog 
entries.  An  examination  of  the  catalog  attribute  class  provides  a  clearer  distinction  between  parts  and 
catalog  entries.  The  class  attribute  identifies  the  type  of  entity  that  can  be  cataloged;  it  encompasses 
software  entities  such  as  package  specifications,  package  bodies,  generic  task  specifications,  generic  task 
bodies,  generic  formal  parts,  and  context  clauses. 

It  should  be  noted  that  there  is  a  hardcopy  form  of  the  CAMP  software  catalog  as  well  as  the 
on-line  version  that  is  incorporated  into  the  AMPEE  Parts  Catalog  subsystem.  The  hardcopy  form  is 
useful  for  those  who  do  not  have  access  to  the  AMPEE  system.  The  on-line  version  provides  specific 
information  on  available  reusable  software  parts  from  within  the  AMPEE  system. 

( 1 )  Design 

The  AMPEE  Parts  Catalog  subsystem  allows  a  user  of  the  AMPEE  system  to  access  and 
maintain  the  CAMP  parts  catalog  entries.  Maintenance  functions  include  functions  to  add  entries  for  new 
or  revised  reusable  software  entities,  and  to  modify  or  delete  entries.  Locating  functions  include  func¬ 
tions  to  search  for  catalog  entries  based  on  various  attribute  values,  examine  both  catalog  entries  and  Ada 
part  source  code,  and  to  generate  printed  versions  of  the  catalog  entries.  Catalog  interaction  is  carried  out 
via  a  structured  dialog  between  AMPEE  and  the  user;  the  user  provides  all  information  necessary  for  the 
system  to  implement  his  catalog  request.  Figure  25  depicts  the  functions  that  comprise  the  Parts  Catalog 
subsystem. 


Figure  25.  Parts  Catalog  Functions 


For  operations  that  can  be  performed  on  an  existing  catalog  entry,  the  user  can  provide  a 
specific  part  id.  request  a  menu  of  all  part  ids,  or  request  a  menu  of  part  ids  in  the  current  search  list.  The 
search  list,  if  it  exists,  is  a  list  of  (he  part  ids  that  have  satisfied  the  search  criteria  specified  during  the 
most  recent  search  operation,  or  have  been  returned  by  one  of  the  Parts  Identification  functions. 

The  Add  Part  Description  function  allows  the  user  to  add  an  entry  to  the  CAMP  parts 
catalog  for  a  new  or  revised  CAMP  software  part.  This  can  be  done  in  one  of  three  ways: 

•  A  new  part  description  of  a  new  part  is  entered  (i.e.,  "from  scratch") 
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•  A  new  part  description  for  a  revision  of  an  existing  part  is  entered 

•  A  new  part  description  of  a  new  part  is  entered  by  copying  the  part  description  of  an  existing  part 
and  modifying  it  as  needed. 

A  unique  part  id  is  generated  for  each  part  that  is  entered.  The  part  id  consists  of  a  part 
number  and  a  revision  number,  and  is  not  intended  to  have  any  semantic  meaning.  The  user  is  led 
through  the  addition  of  required  and  recommended  attributes  for  each  part  entry  that  is  added  to  the 
catalog.  Requited  attributes  are  those  which  have  been  deemed  to  be  essential  in  providing  the  catalog 
user  with  sufficient  information  to  make  an  informed  decision  as  to  the  appropriateness  of  a  given  CAMP 
Ada  part.  Required  attributes  are  enumerated  in  Figure  26.  Two  additional  attributes,  withs  and  withed 
by,  are  defined  as  required,  but  because  they  may  not  always  be  applicable,  it  is  the  user’s  responsibility 
to  provide  them.  Recommended  attributes  are  those  that,  although  they  provide  useful  information,  are 
not  usually  critical  to  making  a  determination  as  to  the  appropriateness  of  a  part. 

The  AMPEE  system  provides  the  values  of  some  attributes  such  as  the  revision  number, 
date  of  change  of  the  catalog  entry,  and  values  for  inverses  (e.g.,  if  the  user  enters  built  ft  om  data,  the 
system  will  automatically  update  the  appropriate  other  catalog  entries  with  used  to  build  data).  Other 
attribute  values  must  be  explicitly  provided  by  the  user. 

Part  Number 
Revision  Number 
Part  Name 

Taxonomelric  Category 
Functional  Abstract 
Class 
Mode 

Last  Change  Date  of  Entry 
Development  Date 
Developer 
Development  Status 

Government  Security  Classification  of  Part 
Government  Security  Classification  of  Entry 
Corporate  Sensitivity  Level  of  Part 
Corporate  Sensitivity  Level  of  Entry 

Figure  26.  Required  Catalog  Attributes 

The  Modify  Part  Entry  function  allows  the  user  to  modify  an  existing  entry  in  the  CAMP 
software  parts  catalog.  After  indicating  which  part  entry  is  to  be  modified,  the  user  is  allowed  to  select 
the  attributes  that  are  to  be  modified.  He  then  provides  the  system  with  the  new  data  so  that  the  catalog 
entry  can  be  updated. 

The  Delete  Part  Entry  function  allows  the  user  to  delete  an  entry  from  the  CAMP  software 
parts  catalog.  The  user  must  indicate  which  part  entry  is  to  be  deleted;  that  entry  is  then  deleted  from  the 
current  catalog.  In  order  for  the  deletion  to  be  permanent,  the  user,  upon  exiting  the  AMPEE  system, 
must  indicate  that  all  catalog  changes  made  during  the  current  session  are  to  be  saved. 

The  Search  function  allows  the  user  to  explore  the  reusable  software  parts  that  are  avail¬ 
able  to  him.  Inquiry  can  take  place  along  a  number  of  lines  (e.g.,  keywords  or  other  attributes),  and 
multiple  selection  criteria  are  supported. 
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For  the  keyword  search,  the  user  must  identify  the  keywords  and/or  phrases  that  are  to  be 
used  as  the  selection  criteria.  Within  the  parts  catalog,  keywords  are  generally  entered  for  high-level  parts 
only  (this  reduces  the  number  of  parts  that  will  be  returned  by  a  search,  thus  making  it  more  meaningful); 
other  attributes,  such  as  built  from ,  can  be  used  to  obtain  related  parts.  For  the  searches  on  other  at¬ 
tributes,  the  user  must  identify  both  the  attribute  name  and  value  to  be  used  as  the  selection  criteria.  The 
searchable  attributes  are  enumerated  in  Figure  27. 

If  any  matches  are  found  during  the  search,  their  part  ids  are  displayed  for  the  user,  and  the 
list  of  part  ids  for  the  matches  is  kept  for  further  manipulation.  The  user  can  specify  further  search 
criteria  to  be  applied  to  the  parts  in  the  search  list,  or  he  can  select  part  ids  from  the  list  for  further 
processing  (e.g.,  deletion,  examination  of  catalog  entry  or  source  code).  If  no  matches  are  found,  then  a 
message  is  displayed  indicating  this. 

Pari  Name 

Mode  (Bundled,  Unbundled,  or  Schematic) 

Tax onome trie  Category 
Class 

Government  Security  Class  of  Part 
Government  Security  Class  of  Entry 
Corporate  Sensitivity  Level  of  Part 
Corporate  Sensitivity  Level  of  Entry 
Project  Usage 
Last  Change  Date  of  Entry 
Implements 
Implemented  By 
Withs 
Withed  By 
Built  From 
Used  to  Build 
Location  of  Source  Code 
Developer 
Developed  For 
Development  Date 
Development  Status  I 

Figure  27.  Searchable  Catalog  Attributes 

The  Examine  Pari  Description  function  allows  a  user  to  retrieve  and  examine  a  catalog 
entry  for  a  specified  part  in  the  CAMP  parts  catalog.  The  user  must  identify  the  part  entry  that  is  to  be 
examined.  He  can  then  view  the  basic  attributes  (i.e..  part  id,  name,  last  change  date  of  entry,  develop¬ 
ment  date,  development  status,  developer,  mode,  class,  taxonometric  calegory,  and  government  and  cor¬ 
porate  sensitivity  levels  of  the  part  and  part  entry),  or  select  additional  attributes  to  view. 

The  cataloged  software  parts  are  classified  in  part  by  their  mode  (i.e.,  whether  they  are 
bundled,  unbundled,  or  schematic  parts);  Appendix  B  describes  this  attribute  in  more  detail.  The  Ex¬ 
amine  Source  Code  function  allows  the  AMPEE  system  user  to  examine  the  actual  source  code  for 
reusable  CAMP  parts  that  are  classified  as  either  bundled  or  unbundled  parts.  Schematic  parts  cannot  be 
examined  because  there  is  no  actual  source  code  until  a  component  is  constructed  via  the  AMPEE  system. 

The  Print  Catalog  Entry  function  provides  the  user  with  the  ability  to  obtain  a  formatted 
hardcopy  of  one  or  more  catalog  entries.  The  user  can  process  the  entire  catalog,  entries  obtained  from  a 
search  list,  or  individually  identified  entries.  Output  may  be  sorted  in  ascending  order  by  part  id  or 
alphabetically  by  taxonometric  category.  The  user  has  two  options  in  directing  the  output:  he  can  have  it 
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print  to  both  the  screen  and  to  a  file,  or  just  to  a  file.  Formatting  is  performed  via  the  text  processing 
program  Scribe.  Because  of  limitations  of  the  Scribe  system,  it  is  not  possible  to  view  text  interactively 
after  it  is  formatted  by  the  Seri  je  processor;  thus  the  output  displayed  on  the  screen  is  not  identical  to  that 
produced  for  printing. 

(2)  Testing  and  Operational  Evalnation 

The  AMPEE  Parts  Catalog  subsystem  underwent  several  levels  of  testing; 

•  Testing  by  (he  subsystem  developer 

•  Use  for  entry  of  catalog  data 

•  Use  by  the  AMPEE  system  training  class 

Testing  was  performed  by  the  subsystem  developer  to  eliminate  both  programming  errors, 
and  interface  errors  or  inconsistencies.  Although  this  type  of  testing  is  important,  it  cannot  uncover  all  of 
the  problems  tliat  may  exist. 

The  Parts  Catalog  subsystem  was  used  for  the  entry  of  data  into  the  catalog.  This  data 
entry  was  performed  by  a  number  of  persons  with  varying  backgrounds,  including  a  high  school  student 
with  no  previous  exposure  to  the  system;  a  college  student  with  no  software  engineering  training,  a 
member  of  the  PCS  development  team  who  had  not  worked  on  this  particular  subsystem,  and  the  senior 
member  of  the  parts  development  team.  All  of  these  users  were  able  to  successfully  use  the  system  with 
very  little  instruction,  and  some  with  very  little  background  knowledge  of  the  project  itself.  Although 
these  users  were  able  to  easily  pick  up  the  knowledge  needed  to  perform  data  entry,  they  did  uncover 
inconsistencies  in  the  interface,  and  highlighted  some  areas  for  improvement.  As  a  result  of  this  use, 
several  additional  subfunctions  were  added  (e.g.,  add  new  part  by  copying  existing  entry). 

This  subsystem  was  also  used  by  the  AMPEE  system  training  class  for  instructional  pur¬ 
poses.  These  users  also  found  the  interaction  to  be  relatively  straightforward,  but  they  also  uncovered 
several  inconsistencies  and  a  few  minor  errors  that  had  not  been  previously  identified. 

Overall,  the  AMPEE  Parts  Catalog  subsystem  was  found  to  be  useful,  although  several 
problems  were  identified.  These  were  mostly  a  result  of  the  prototype  nature  of  the  system,  and  included 
items  such  as  response  time  and  start-up  lime.  Some  users  also  thought  the  system  could  be  improved  by 
providing  greater  carry-over  between  the  functions  within  the  AMPEE  system. 
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I).  Parts  Identification 


The  Parts  Identification  subsystem  provides  the  user  with  two  capabilities  for  determining  the 
availability  of  potentially  applicable  parts  for  a  given  software  system;  the  functions  map  software  re¬ 
quirements  to  software  parts.  The  user,  who  would  generally  be  a  missile  system  engineer  or  a  missile 
software  requirements  engineer,  can  provide  the  system  with  his  requirements  and  determine  the  parts 
that  may  be  applicable  to  his  project.  Although  the  Parts  Catalog  subsystem  also  provides  information  on 
the  potential  applicability  of  parts,  (he  Parts  Identification  functions  provide  this  information  at  a  higher 
level,  i.e.,  the  user" does  not  need  to  know  about  specific  parts  to  obtain  information;  he  need  only  provide 
information  about  his  application. 

The  Parts  Identification  functions  are  intended  for  use  early  in  the  development  cycle  —  as 
early  as  the  missile  system  requirements/design  phase,  or  in  the  pre-software  development  phase.  Their 
use  this  early  can  help  drive  the  design  in  a  direction  that  can  make  maximum  use  of  existing  software.  If 
software  designers  wait  until  after  the  requirements  and  design  phase  to  start  exploring  options  for  reuse 
of  existing  software,  it  is  generally  too  late.  At  that  point,  the  design  may  be  such  that  certain  parts  are 
excluded  from  reuse.  In  addition  to  driving  the  design,  the  Parts  Identification  functions  can  also  be  used 
to  facilitate  software  cost  estimates,  sizing  and  timing  studies,  and  make-or-buy  trade-off  studies. 

During  die  CAMP  study,  two  approaches  to  software  parts  identification  were  identified.  One 
is  an  application  approach,  (hat  looks  at  overall  system  requirements.  By  viewing  the  system  as  a  whole, 
the  user  can  see  die  effect  of  various  trade-offs  in  algorithms.  Consistency  can  also  be  provided  by 
ensuring  that  parts  identified  for  the  user  are  not  incompatible.  The  architectural  approach  looks  at  the 
subsystems  (hat  are  needed  in  a  particular  missile  system.  Tliis  approach  is  based  on  hierarchical  models 
of  missile  flight  software.  The  user  provides  information  on  his  application  and  a  model  is  presented  for 
his  viewing.  He  can  then  see  the  subsystems  and  parts  may  be  needed.  Both  approaches  have  been 
incorporated  into  the  AMPEE  system  —  the  application  approach  is  embodied  in  Application  Explora¬ 
tion,  and  the  architectural  approach  is  embodied  in  Missile  Model  Walkthrough. 

(1)  Application  Approach 

The  application  approach  to  parts  identification  is  embodied  in  the  Application  Exploration 
function  within  the  AMPEE  system.  Application  Exploration  provides  the  user  with  the  capability  of 
mapping  high-level  requirements  to  available  software  parts.  It  is  intended  for  use  early  in  a  software 
development  project  to  identify  software  parts  with  potential  applicability  to  the  user’s  current  needs.  The 
user  is  asked  a  number  of  questions  about  his  application,  and  a  list  of  potentially  applicable  parts  is 
generated.  For  each  part  in  the  list,  the  part  id,  part  name,  and  the  missile  subsystem  to  which  the  part 
belongs  is  displayed.  The  generated  list  of  parts  can  be  carried  over  into  the  Parts  Catalog  subsystem,  i.e., 
given  the  list  of  parts  returned  by  tliis  function,  the  user  can  enter  the  Parts  Catalog  subsystem  and 
examine  the  part  entries  or  source  code,  print  the  entries,  or  perform  other  catalog  functions.  Figure  28 
depicts  a  high-level  view  of  this  function;  Table  5  describes  the  user  inputs. 

The  data  required  from  the  user  includes  information  on  the  launch  platform,  target  and 
warhead  type,  whether  an  aiding  subsystem  is  needed,  routing,  seeker,  the  type  of  aerodynamic  control, 
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the  navigational  range,  and  the  type  of  interfaces.  Application  Exploration  includes  both  rule-based  and 
parts- based  reasoning.  For  example,  if  the  user  indicates  that  the  target  is  a  ship,  then  the  AMPEE  system 
will  conclude  that  a  seeker  is  needed  in  the  system.  If  a  seeker  is  needed,  the  AMPEE  system  knows  that 
there  are  no  specific  seeker  parts,  but  recommends  the  use  of  math  parts,  the  Data  Bus  Interface  Construc¬ 
tor,  and  the  Finite  State  Machine  Constructor  for  construction  of  the  required  seeker  software.  Figure  29 
shows  an  example  of  the  inputs  and  outputs  of  Application  Exploration. 


(2)  Architectural  Approach 

The  architectural  approach  to  parts  identification  is  embodied  in  the  Missile  Model 
Walkthrough  function  within  the  AMPEE  system.  Missile  Model  Walkthrough  provides  the  user  with  the 
ability  to  walk  through  a  hierarchical  model  of  missile  flight  software.  The  models  used  by  this  function 
are  hierarchical  models  of  missile  flight  software  based  on  knowledge  of  the  parts  required  for  missiles  of 
various  types  (e.g.,  it  has  been  determined  that  anti-ship  missiles  require  a  particular  set  of  software  parts, 
and  it  is  this  set  of  parts  that  form  a  hierarchical  model  of  software  parts  required  for  this  type  of  missile). 
The  user  can  traverse  the  model,  going  up,  down,  or  sideways.  The  model  displayed  for  the  user  shows 
the  subsystems,  functions,  and  CAMP  parts  that  may  be  applicable  for  the  missile  described  by  the  user. 
Figure  30  depicts  a  high-level  view  of  this  function. 
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TABLE  5.  APPLICATION  EXPLORATION  —  REQUIRED  USER  INPUTS 


USER  INPUTS 

DESCRIPTION 

Launch  Type 

Air  1  Ground  1  Surface-Sea  1  Submerged-Sea 

Warliead  Type 

Conventional-Submunition  1  Conventional  Unitary  1  Multiple- 
Nuclear  f  Singular-Nuclear 

1  argcl  1  ype 

Air  1  Fixed-Wing  Air  1  Helicopter  Air  1  Strategic-Missile  Air  1 
Tactica!  Conventional  Air  i  Tactical-Nuclear  Air  1  Fixed  Ground  1 
Mobile  Oround  1  Surface-Sea  1  Submerged-Sea 

E 

An  integer  representing  nautical  miles.  Applicable  if  target  is  any 
type  of  air. 

liiliM 

Applicable  if  target  type  is  ground  (fixed  or  mobile)  and  launch 
type  is  sea. 

Aiding,  seeker,  or 
both 

Applicable  if  target  type  is  mobile -ground,  launch  type  is  not 

air,  warhead  is  conventional  unitary,  and  no  aiding  or  seeker  has 
been  specified. 

Type  of  aiding 

GPS  1  Terrain  Map  1  Digital  Scene  Map  1  Laser  Radar  1  Doppler 
Velocity  1  Infrared  User  is  queried  for  this  information  if  target 
type  is  ground  (fixed  or  mobile)  or  se*,  or  if  aiding  aubsystem  is 
wanted. 

Seeker 

Applicable  if  1)  User  specified  seeker  is  wanted  (in  cjuery  above); 

2)  Target  type  is  surface-sea,  warhead  is  not  conventional  unitary, 
and  no  aiding  or  seeker  has  hecn  specified;  3)  Launch  type  is 
air,  target  type  is  mobile  ground,  and  warhead  is  conventional 
unitary:  4)  Target  type  is  any  type  of  air  and  no  seeker  has  yet 
been  specified. 

Type  of  seeker  (non 
air  targets) 

Imaging  Infrared  1  Radar  1  Optical 

Type  of  seeker  (air 
targets) 

Infrared  1  Imaging  Infrared  1  Passive  Radar  1  Aclive  Radar 

Applicable  if  large!  type  in  surface-sea. 

0-’  * 

Land  1  Sea  Applicable  if  target  type  is  ground  or  sea. 

HO! 

This  can  be  eilher  classical  or  modern,  but  is  determined  by 
querying  the  user  as  to  the  required  performance,  robustness,  and 
stability  of  his  missile. 

Kalman  filter  in¬ 
cluded  j 

Applicable  if  it  is  determined  that  modem  control  dynamics  is 
being  used. 

Error  estimation 

1  state  1  2+  stales  Applicable  if  Kalman  filter  is  to  be  included  in 
system  using  modem  control  dynamics. 

Navigation  near  the 
poles 

Yes  1  No 

Type  of  navigation 

North-Pointing  1  Wander-Azimuth  Applicable  if  navigation  is  not 
taking  place  near  the  poles. 

Interface  Require- 
me  nts 

155.1 1  K82  1 IEEE488  1  RS-2,12 
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Advanced  Medium  Range  Air-to-Alr  Miss 
( AMRAAM ) 


Launch 

Target 

Rang* 

Warhead 

Aiding 

Routing 

Saakar 

Aerodynamic* 

Navigation 

Interface* 


Air 

Air 

25+  NM 

Conventional 

No 

Air 

Active  Radar 
Standard 
Standard 
Data  Link 


Parts  Selects 


Navigation 
Kalman  filter 
Autopilot 
CoMuni  cation* 

Air  Data 

Coordinate  V/M  Algebra 
Signal  Proeeaaing 


Data  Source:  Jana's  Weapon  Systems.  1986-1987,  pp198-200 

Figure  29.  Application  Exploration  Example 


Figure  30.  Missile  Model  Walktitrough 


Missile  model  selection  is  based  on  the  user-provided  values  for  target  type  and  type  of 
warhead;  CAMP  work  to  date  has  indicated  that  launch  type  is  not  a  factor  in  missile  model  selection. 
Additional  information  may  be  requested  from  the  user.  Once  the  user  has  provided  the  information 
requested,  he  will  be  be  able  to  view  and  traverse  a  graphical  representation  of  the  missile  software 
structure. 

The  missile  software  systems  examined  during  the  CAMP  domain  analysis  all  contained 
certain  subsystems  regardless  of  (he  target  type;  additional  subsystems  were  needed  based  on  the  target 
category.  For  instance,  if  the  target  type  is  some  form  of  air  target,  the  missile  may  require  the  following 
subsystems  in  addition  to  the  standard  ones:  Kalman  filter,  waypoint  steering,  telemetry,  data  link,  seeker. 
If  the  target  category  is  sea  and  it  is  located  in  a  harbor,  then  an  aiding  subsystem  will  be  identified  in 
addition  to  the  usual  missile  software  subsystems.  Missiles  whose  targets  are  stationary  land  may  require 
data  link  and  aiding  subsystems,  while  mobile  land  targets  may  also  require  a  seeker  subsystem. 

The  missile  software  hierarchy  is  captured  within  the  Missile  Model  Walkthrough  function 
via  ART  schemata  and  inheritance  relations.  Inheritance  relations  allow  properties  to  be  attributed  to  a 
particular  class  of  objects  and  to  have  (hose  properties  hold  true  for  a  subclass  that  inherits  from  the 
original  class  of  objects.  A  schema  is  used  to  capture  the  basic  information  about  all  missile  software 
systems;  this  is  then  inherited  by  missiles  of  a  particular  type,  such  as  air-to-air  or  air-to-sea.  The  par¬ 
ticular  missiles  generally  require  software  subsystems  in  addition  to  those  required  by  the  basic  missile 
software  system. 

ART  rules  arc  used  to  check  the  user's  input  for  consistency.  For  example,  if  the  user 
indicates  a  target  type  of  air  and  a  warhead  type  of  nuclear,  a  warning  will  be  issued  to  the  user  to  tell  him 
that  this  is  probably  not  allowed  under  the  Anti-Ballistic  Missile  Treaty.  Rules  also  direct  portions  of  the 
user  interface,  controlling  when  the  user  is  queried  for  different  types  of  information. 

(.1)  Testing  mid  Operational  Evaluation 

Like  the  Parts  Catalog  subsystem,  the  Parts  Identification  subsystem  underwent  several 
types  of  informal  testing  and  use.  Development  involved  close  collaboration  between  an  expert  and  the 
subsystem  developer;  thus  the  first  level  of  testing  involved  both  the  expert  and  the  developer.  Develop¬ 
ment  and  testing  were  iterative.  The  developer  was  able  to  detect  and  correct  programming  errors,  while 
(he  expert  was  able  to  detect  errors  in  (he  knowledge  base.  The  subsystem  underwent  further  user  testing 
during  the  PCS  training  class.  Few  problems  were  delected  with  the  system. 

Although  this  subsystem  was  not  heavily  used  during  CAMP-2,  it  has  high  potential  within 
the  software  development  arena.  One  reason  for  its  lack  of  use  during  the  CAMP  project,  was  the 
familiarity  of  the  engineering  staff  with  the  CAMP  parts  —  there  was  no  need  to  use  this  function. 
Additionally,  because  the  AMPEE  system  is  a  prototype,  the  Missile  Model  Walkthrough  function  took 
advantage  of  the  ART  Studio  for  the  display  of  the  model;  this  was  sufficient  to  convey  the  information  to 
the  user,  but  it  was  less  than  optimal  in  clarity. 
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c.  Component  Constructors 

The  Component  Construction  subsystem  is  the  third  major  subsystem  of  the  AMPEE  system,  it 
comprises  a  number  of  component  constructors.  A  component  constructor  is  a  software  system  that 
facilitates  the  development  of  application  software  by  producing  software  components  based  on  user 
requirements.  Each  constructor  in  the  AMPEE  system  is  based  on  a  CAMP  meta-part. 

A  meta-part  may  be  either  a  complex  Ada  generic  or  a  schematic  part.  A  complex  generic  part 
may  require  data  types,  operators,  and/or  subprograms  for  instantiation,  and  may  include  a  complex 
defaulting  scheme;  simple  generic  parts  require  only  a  small  number  of  data  types  for  instantiation. 
Schematic  parts  are  parts  whose  design  is  well  known,  but  that  cannot  be  implemented  via  the  Ada 
generic  facility  alone.  Schematic  parts  consist  of  a  blueprint  for  construction,  and  a  set  of  construction 
rules  for  building  a  specific  instance  of  the  part.  With  schematic  parts,  there  is  no  actual,  complete, 
compilable  piece  of  code  until  a  specific  instance  is  generated  for  the  user.  Constructors  for  complex 
generic  parts  assist  (he  user  in  defining  types,  objects,  and  subprograms  needed  to  instantiate  the  parts, 
and  then  produce  the  code  that  includes  those  types,  objects  and  subprograms,  as  well  as  (he 
instantialion(s)  of  the  CAMP  part(s).  Constructors  for  schematic  pans  obtain  input  from  die  user, 
generate  the  needed  code  based  on  both  the  user’s  input  and  the  schematic  design  that  is  incorporated  into 
the  constructor.  The  difference  in  forms  is  transparent  to  the  AMPEE  system  user;  implementation  dif¬ 
ferences  are  discussed  in  Section  IV.2.d.  Examples  of  meta-parts  follow. 

The  finite  slate  machine  is  a  schematic  part  for  which  a  constructor  has  been  developed.  Cer¬ 
tain  types  of  finite  state  machines  allow  procedures  to  be  invoked,  therefore,  this  part  cannot  be  captured 
via  the  Ada  generic  facility  because  procedures  cannot  be  passed  as  parameters.  Additionally,  the  vari¬ 
able  number  of  states  and  transitions  in  a  finite  state  machine  are  difficult  to  capture  in  generic  units.  All 
of  this  aside,  most  software  engineers  have  a  good  idea  of  how  a  finite  state  machine  can  be  implemented. 
This  type  of  situation  led  to  the  concept  of  schematic  parts.  The  Finite  Stale  Machine  Constructor  allows 
the  user  to  specify  an  initial  state,  terminal  states,  state-transitions,  and  any  actions  that  may  be  associated 
with  either  the  states  or  transitions,  and  then  generates  the  Ada  code  that  implements  this  machine. 

The  CAMP  autopilot  parts  are  complex  generic  parts,  and  a  constructor  is  provided  to  assist  the 
user  in  the  correct  instantiation  of  those  parts.  Various  data  type,  data  object  and  subprogram  definitions 
are  required.  The  constructor  has  specific  knowledge  of  the  complex  generic  part  and  prompts  the  user  for 
the  information  needed  to  define  the  types,  objects,  and  subprograms  required  for  the  instantiations. 

The  Kalman  Filter  Constructor  combines  elements  of  both  complex  generic  units  and 
schematics  depending  on  the  options  selected  by  the  user.  In  the  simplest  case,  the  user  can  choose  to  let 
most  of  the  data  types  information  default;  to  the  extent  possible,  CAMP  parts  will  be  used  for  types  and 
operators.  When  efficiency  is  of  concern,  the  user  can  let  the  constructor  help  him  define  special  purpose 
data  types  (i.e.,  special  forms  of  matrices)  that  will  be  incorporated  into  the  Kalman  filter  code  that  is 
generated.  These  special-purpose  matrices  capture  the  active  elements  of  a  sparse  matrix  and  unfold  the 
operations.  This  eliminates  the  overhead  involved  in  using  full-storage  matrices  that  operate  on  all  ele¬ 
ments  in  a  matrix. 

Although  the  CAMP  component  constructors  generate  code,  they  do  not  perform  universal  code 
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generation,  but  rather  code  generation  in  a  limited  domain,  i.e.,  within  ihe  confines  of  the  meta-part 
requirements.  During  the  CAMP-1  feasibility  study,  it  was  determined  that,  because  of  efficiency  re¬ 
quirements,  universal  code  generation  was  not  yet  feasible  in  real-time  embedded  applications.  The 
AMPEE  system  component  constructors  produce  code  that  is  as  efficient  as  possible  given  the  input 
supplied  by  (he  user. 

The  constructors  reduce  the  user’s  need  for  both  detailed  Ada  knowledge  (because  the  code 
itself  is  generated  for  the  user)  and  for  detailed  knowledge  about  the  software  parts  on  which  the  con¬ 
structors  are  based.  A  straightforward  user-interface  is  provided  to  facilitate  requirements  specification  by 
the  user.  These  requirements  are  analyzed  by  the  constructor  and  tailored  Ada  code  is  produced.  The 
constructors  arc  intended  for  use  by  application  developers,  and  can  be  used  both  for  trying  out  what  ifs 
and  for  actual  software  development. 

The  user  must  have  some  knowledge  of  Ada  because  he  will  often  be  prompted  to  provide 
information  needed  to  define  data  types,  data  objects,  and  subprograms.  He  must  also  have  some 
familiarity  with  the  application  area  in  order  to  be  able  to  produce  meaningful  output.  The  AMPEE 
system  parts  catalog  can  be  used  to  obtain  detailed  information  on  the  parts  on  which  the  constructors  are 
based,  thus  the  user  will  not  need  to  be  intimately  familiar  with  the  parts  themselves. 

The  constructors  provide  (he  user  with  the  ability  to  generate  tailored  Ada  components,  modify 
the  component  requirements  (either  in  place  or  after  making  a  copy)  and  regenerate  the  component,  and 
delete  the  requirements  upon  which  the  components  are  based.  Component  regeneration  may  be  neces¬ 
sary  if,  after  a  user  has  generated  a  component,  he  realizes  he  must  alter  some  of  the  requirements. 

Although  each  meta-part  is  associated  with  its  own  component  constructor  which  guides  the 
software  generation  process,  and  each  constructor  has  its  own  requirements  and  design,  the  top-level 
design  of  all  of  the  constructors  follows  the  basic  paradigm  of  inputs-processing-outputs  (see  Section 
IV.2.d).  The  inputs  arc  the  component  requirements  provided  by  the  user,  and  the  major  output  is  the 
tailored  Ada  software  component.  Processing  consists  of  interacting  with  the  user,  checking  of  input  data, 
internal  processing  to  transform  the  data  into  a  usable  form,  and  writing  out  the  application-specific  Ada 
code. 
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The  constructors  that  comprise  the  AMPEE  system  are  summarized  below. 


•  Kalman  Filler  Constructor:  The  Kalman  Filter  Constructor  provides  the  user  with  a  tailored  version 
of  the  CAMP  Kalman  filler  parts,  plus  the  data  types  that  are  needed  to  support  Kalman  filler 
operations. 

•  Finite  Stale  Machine:  The  Finite  State  Machine  Constructor  will  construct  one  of  three  varieties  of 
finite  state  machines  (Mealy  machine,  Moore  machine,  or  a  finite  stale  machine  with  no  actions). 

•  Pitch  Autopilot  Constructor:  The  Pitch  Autopilot  Constructor  provides  an  Ada  pitch  autopilot 
component,  plus  the  required  data  types,  filters,  and  a  limiter. 

•  Lateral/Directional  Autopilot  Constructor:  The  Lateral/Directional  Autopilot  Constructor  provides 
an  Ada  implementation  of  a  lateral/directional  autopilot,  plus  the  required  data  types,  filters,  and 
limiters. 

•  Navigation  Subsystem  Constructor:  The  Navigation  Subsystem  Constructor  provides  a  single 
navigation  subsystem  composed  of  selected  navigation  computations. 

•  Navigation  Component  Constructor:  The  Navigation  Component  Constructor  provides  a  set  of 
individual  navigation  computation  components. 

•  Data  Bus  Interface  Constructor:  The  Data  Bus  Interface  Constructor  provides  the  user  with  a 
general-purpose  interface  to  a  data  bus. 

•  Data  Type  Constructor:  This  constructor  assists  the  user  in  the  definition  of  various  Ada  data  types. 

•  Abstract  Processes  Constructors:  There  are  four  constructors  in  this  category:  a  Task  Shell  Con¬ 
structor,  Time-  and  Event-Driven  Sequencer  Constructors,  and  a  Process  Controller  Constructor. 

(1)  Design  Paradigms 

A  standard  paradigm  for  constructor  design  and  a  methodology  for  component  constructor 
development  was  developed  under  CAMP-2.  The  standard  design  paradigm  promotes  consistency,  ease 
of  integration,  and  standardization  of  user  interfaces.  The  standard  methodology  facilitates  the  develop¬ 
ment  process;  it  stresses  many  informal  reviews  as  work  progresses,  and  is  iterative  in  nature.  The 
paradigm  for  constructor  design  covers  three  areas: 

•  The  user  interface 

•  The  processing  or  analysis  phase 

•  The  code  generation  or  synthesis  phase 

The  need  for  constructors  can  be  identified  either  by  projects  who  recognize  the  need  for  a 
constructor  or  through  domain  analysis  performed  by  a  parts  group.  The  constructors  that  comprise  the 
AMPEE  system  were  identified  during  die  domain  analysis  of  CAMP-1.  Constructors  can  be  developed 
both  to  assist  in  the  use  and  tailoring  of  complex  Ada  generic  parts,  and  to  produce  tailored  Ada  code 
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from  schematic  designs.  Once  it  is  thought  that  a  new  constructor  is  needed,  an  intensive  analysis  should 
be  performed  to  determine  if  there  is  sufficient  demand  for  such  a  constructor  to  warrant  the  non-trivial 
development  cost.  For  example,  the  Kalman  Filter  Constructor  comprises  some  8000+  lines  of  Lisp/ART 
code  and  has  access  to  another  2700  lines  of  code  in  common  utilities. 

The  user  interface  front-end  elicits  requirements  from  the  user  for  the  software  component 
that  is  to  be  generated;  the  processing  portion  then  converts  the  requirements  into  an  internal  represen¬ 
tation;  and  the  back-end,  or  synthesis  phase,  generates  the  required  Ada  code  for  ihe  user.  Figure  31 
illustrates  this  design  paradigm. 


Figure  31.  Constructor  Design  Paradigm 


The  user’s  requirements  undergo  analysis  for  completeness  and  consistency,  and  are  then 
stored  m  an  intermediate  form.  The  synthesis  phase  generates  the  Ada  code  from  the  requirements 
provided  by  the  user.  The  code  can  consist  of  generated  Ada  components,  instantiations  of  complex  Ada 
generic  units,  or  a  combination  of  instantiations  and  generated  code. 

Early  in  the  development  process,  the  constructor  developer  formulates  preliminary  re¬ 
quirements  and  questions  for  Ihe  expert ,  i.e.,  the  Ada  parts  developer.  The  parts  developer  must  then 
consider  these  requirements  with  the  following  issues  in  mind: 

•  What  CAMP  parts  can  or  should  be  used? 

•  What  alternatives  should  Ihe  user  be  presented  with  (e.g..  Should  he  only  be  able  to  put  together 
CAMP  parts  when  constructing  the  component  or  should  he  also  be  able  to  provide  his  own 
parts?)? 

•  What  information  should  be  elicited  from  Ihe  user  (i.e..  the  wording  of  the  interface  is  important  — 
it  should  be  in  the  domain  language)? 

•  What  are  the  implications  of  different  choices  made  by  the  user? 


Following  this  preliminary  work,  the  constructor  developer  and  the  parts  team  member 
responsible  for  the  design  of  the  corresponding  Ada  part  should  meet  to  delineate  the  scope  of  the  con¬ 
structor,  clarify  requirements  (inputs,  processing,  and  outputs),  and  determine  acceptance  criteria.  After 
this  initial  meeting,  the  constructor  developer  begins  defining  the  dialog  that  will  be  conducted  with  the 
user.  This  process  includes  the  development  of  preliminary  screen  flow  diagrams.  These  diagrams  depict 
the  actual  user  interface  for  the  constructor.  Early  development  of  these  diagrams  helps  to  point  out 
omissions  in  the  requirements  and  misunderstandings  between  the  intent  of  the  Ada  part  designer  and  the 
constructor  designer. 

After  several  iterations  on  the  preliminary  screen  flow  diagram,  the  constructor  developer 
produces  a  complete  screen  flow  diagram  that  depicts  the  user  interface  for  the  four  constructor  functions 
—  Generate,  Browse  I  Modify,  Copy/Modify,  and  Delete.  A  standard  symbology  for  the  screen  flow 
diagrams  has  been  developed  (see  Figure  32). 
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Figure  32.  Screen  Flow  Symbology 


A  second  diagram  depicting  the  high-level  view  of  the  constructor  is  also  produced.  This 
diagram  depicts  the  CAMP  parts  that  will  be  used,  the  packages  that  will  be  provided  by  the  user,  and  the 
packages  that  will  be  output  from  this  constructor.  It  shows  the  major  options  available  to  the  user.  As 
an  example.  Figure  33  depicts  the  top-level  view  of  the  Kalman  Filter  Constructor.  The  user  has  several 
choices  to  make.  He  can  choose  between  using  Compact  or  Complicated  H  parts.  He  also  has  a  choice  in 
the  provision  of  required  data  types,  operators,  and  subprograms:  he  can  allow  the  data  types  to  default  to 
those  provided  by  the  constructor,  he  can  provide  his  own  package,  or  he  can  define  his  own  data  types 
interactively.  The  output  from  this  constructor  consists  of  a  data  types  package  and  the  actual  Kalman 
filter  component. 

Once  these  two  diagrams  are  completed,  they  s  ^.d  be  reviewed  by  a  team  (fiat  consists 
of  the  Ada  parts  designer,  the  constructor  developer,  and  the  chief  Ada  designer.  The  constructor  design 
generally  encompasses  several  options  for  construction  of  the  component  (these  are  clearly  identified  in 
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CAMP  PARTS 


Figure  33.  Kalman  Filler  Constructor  —  High-Level  View 


the  screen  flow  diagram).  During  (he  review  meelings.  a  determination  is  made  of  which  options  will  be 
implemented  first,  and  the  priority  of  the  other  options.  If  it  is  determined  that  the  screen  flow  meets  the 
requirements  of  the  constructor,  then  the  PCS  developer  may  proceed  with  further  design  and  implemen¬ 
tation  of  the  component  constructor.  This  process  of  diagram  development  and  review  may  be  iterative. 

Upon  successful  completion  of  the  diagrams,  the  constructor  developer  should  produce  a 
program  design  language  (PDL)  description  of  the  constructor  and  the  data  structures  required  for  im¬ 
plementation.  These  may  be  reviewed  informally  prior  to  implementation.  Onrj  the  design  is  complete, 
the  constructor  developer  can  begin  implementation,  concentrating  on  the  options  that  were  assigned  the 
highest  priority. 

The  entire  design  and  development  process  is  iterative  in  nature.  The  approach  developed 
during  CAMP-2  emphasizes  many  informal  reviews  along  the  way.  This  serves  several  purposes:  it 
ensures  that  the  constructor  developer  is  on  track  with  the  requirements  and  design  of  the  constructor,  and 
it  facilitates  communication  with  the  parts  team  (i.e.,  they  are  kept  informed  of  activities  within  the 
component  construction  team). 
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(2)  Constructor  Implementation 

A  standard  structure  has  been  developed  for  implementing  constructors;  this  not  only 
facilitates  integration  but  also  reduces  the  development  time  for  new  constructors.  Common  routines 
have  been  developed  for  AMPEE  system  entry  and  exit,  and  common  constructor  functions.  Utilities 
consist  of  routines  that  perform  error  checking,  and  low-level  processing.  User-interface  functions 
provide  common  routines  that  handle  different  types  of  menus  and  forms  that  are  widely  used.  The 
AMPEE  system  user  interface  utilizes  host  facilities  known  as  presentation  types  to  control  the  type  of 
input  (hat  the  user  may  provide.  This  facility  is  an  extension  to  Common  Lisp,  (he  language  used  for 
AMPEE  system  implementation.  The  presentation  type  facility  allows  data  types  and  error  checking 
routines  to  be  defined  to  limit  the  range  of  valid  inputs. 

The  constructors  are  controlled  by  a  constructor  executive  that  is  constructor-dependent. 
The  executive  is  responsible  for  evaluating  the  functions  in  the  function  list  that  consists  of  the  Lisp 
functions  that  must  be  executed  for  the  particular  constructor  function  (i.e.,  Generate,  Browse  and 
Modify,  Copy  and  Modify,  and  Delete).  A  global  variable  is  used  to  keep  track  of  the  current  location  in 
the  function  list. 


(si)  Types  of  Constructors 

Although  all  of  the  constructors  follow  the  same  basic  design  paradigm,  there  are 
implementation  differences  between  constructors  for  complex  generic  units  and  schematics;  these  are 
transparent  to  the  end-user.  Constructors  for  complex  generic  parts  encode  knowledge  about  instantiation 
of  those  generic  parts;  this  includes  information  on  the  data  types,  operators,  and  subprograms  that  are 
needed  for  instantiation.  Constructors  for  schematic  parts  encode  a  blueprint  or  schematic  of  the  com¬ 
ponent  that  is  to  be  generated;  knowledge  about  Ada  coding  procedures  and  efficiency  issues  is  also 
encoded  in  the  constructors,  e.g.,  within  the  Finite  State  Machine  Constructor  a  decision  is  made  on 
whether  to  use  a  case  statement  or  an  if-tlien-clse  based  on  the  number  of  options  that  will  be  processed. 

lb)  Code  (>enerulion 

Once  all  of  the  infonnation  needed  to  generate  a  component  has  been  obtained  from 
the  user,  code  generation  begins.  The  data  is  extracted  from  the  requirements  schemata,  and  the  ap¬ 
propriate  generic  units  are  instantiated,  or  needed  code  is  generated  based  on  an  existing  blueprint. 

The  code  generation  phase  requires  no  further  interaction  with  the  user.  It  is  driven 
by  requirements  provided  by  the  user  and  encoded  in  the  constructor  itself.  The  code  generation  process 
is  unique  for  each  constructor;  the  complexity  varies  considerably  among  constructors.  In  general,  the 
data  type  definitions  are  generated  first,  followed  by  instantiations  of  CAMP  parts  and/or  production  of 
new  code. 
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(3)  Testing  and  Operational  Evaluation 

The  individual  constructors  and  the  entire  Component  Construction  subsystem  underwent 
various  levels  of  testing,  as  did  the  other  subsystems  that  comprise  the  AMPEE  system.  Constructor 
testing  consisted  of  the  following: 

•  Interface  and  operational  testing  by  the  developer 

•  Informal  user  testing  performed  by  the  PCS  development  team 

•  Code  inspection  pei  formed  by  a  combination  of  the  PCS  team  and  the  parts  team 

•  Compilation  testing  which  was  generally  performed  by  the  constructor  developer 

•  User  testing  by  the  the  PCS  training  class 

Several  of  the  constructors  were  subjected  to  further  testing  and  use,  including  formal 
testing  via  the  CAMP  Ada  parts  test  procedures,  and  use  by  the  1 1th  Missile  team.  When  formal  testing 
was  performed  on  the  output  from  a  constructor,  it  was  conducted  by  a  member  of  the  CAMP  parts  team. 

Overall,  users  found  the  constructors  to  be  a  useful  concept.  The  major  drawback  is  that 
their  implementation  is  closely  linked  to  the  meta-parts  they  represent,  therefore,  changes  to  the  meta¬ 
parts  generally  necessitate  changes  to  the  constructors.  This  is  an  implementation  problem,  not  a  problem 
with  the  concept  of  component  constructor'.  Additionally,  the  constructors  require  more  domain  specific 
knowledge  to  run  than  the  Parts  Catalog  subsystem,  but  that  is  to  be  expected. 

2.  PCS  IMPLEMENTATION 

The  AMPEE  system  was  originally  conceived  as  an  expert  system,  but  it  was  found  that  for  the  most 
part  an  expert  system  was  not  required.  This  divergence  from  the  original  concept  resulted  from  a 
combination  of  factors,  including  one  that  is  quite  common.  In  reviewing  the  literature,  it  is  evident  that 
as  a  problem  becomes  better  understood,  a  sequential  solution  is  often  found  to  a  problem  that  was 
originally  thought  to  be  non-detcrministic. 

a.  System  Architecture 

The  AMPEE  system  is  implemented  using  ART  (the  Automated  Reasoning  Tool  from  In¬ 
ference,  Corp.),  a  commercially  available  expert  system  shell,  and  Common  Lisp.  It  is  hosted  on  a 
Symbolics  3620  computer,  a  single-user  Lisp  workstation,  and  takes  advantage  of  Symbolics  extensions 
to  Common  Lisp.  Figure  34  depicts  this  architecture. 

A  Lisp  machine  differs  from  a  conventional  workstation  such  as  the  DEC  MicroVAX,  in  that  its 
architecture  has  been  developed  to  support  (he  Lisp  programming  language  (although  it  can  be  used  for 
other  languages  as  well),  i.e..  it  is  intended  more  for  symbolic  computation  (him  arithmetic  processing. 
Symbolics  provides  an  extensive  integrated  development  environment.  This  includes  on-line  help, 
documentation,  and  debugging  facilities,  and  incremental  compilation  of  functions  in  the  editor.  Exten¬ 
sive  user  interface  facilities  are  also  provided  in  the  form  of  extensions  to  Common  Lisp. 

An  expert  system  shell  is  a  software  system  that  provides  a  means  for  capturing  knowledge,  and 
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an  inferencing  mechanism  lo  work  on  that  knowledge;  the  application  developer  provides  application 
specific  knowledge  in  (he  form  of  facts  and  rules. 

The  AMPEE  system  was  originally  hosted  on  a  DEC  MicroVAX  and  utilized  DEC  Common 
Lisp  and  beta  versions  of  VAX -compatible  ART.  The  advantages  and  disadvantages  of  each  implemen¬ 
tation  will  be  discussed  in  the  following  paragraphs. 


Figure  34.  AMPEE  System  Architecture 


(I)  Hardware 

The  CAMP- 1  PCS  feasibility  study  included  an  evaluation  of  an  off-the-shelf  expert  sys¬ 
tem  tool  for  use  in  the  PCS.  CAMP- 1  also  required  the  use  of  a  widely  available  processor  both  in  the 
evaluation  of  the  expert  system  tool  and  the  PCS  feasibility  study,  thus  the  DEC  VAX  family  of  com¬ 
puters  was  selected. 

The  VAX  implementation  of  AMPEE,  which  began  as  a  proof-of-concept  implementation 
under  CAMP-1  and  continued  into  the  prototype  stage  under  CAMP-2,  made  use  of  DEC  Common  Lisp, 
DEC  Forms  Management  System  (FMS)  for  the  user  interface,  and  ART  for  the  knowledge  structuring. 
ART  was  selected  in  light  of  (he  hardware  selection  (at  the  lime  of  the  CAMP-1  contract  —  September 
84-85  —  Inference  appeared  closest  to  producing  a  full-scale,  production  quality,  expert  system  develop¬ 
ment  tool  for  the  VAX). 

DEC  FMS  was  used  for  the  interface  in  part  because  the  beta  versions  of  ART  did  not 
provide  adequate  tools  for  the  development  of  a  full-screen  user  interface.  Although  FMS  provided  a 
significant  improvement  over  developing  an  interface  from  scratch,  it  required  a  considerable  initial  effort 
to  use.  The  CAMP  PCS  team  developed  utilities  for  use  with  the  FMS  forms;  these  handled  things  such 
as  forward  and  backward  scrolling,  cursor  positioning,  etc.  The  Lisp-compatible  version  of  FMS  did  not 
provide  automatic  type  checking  of  user-provided  data,  thus,  all  such  processing  had  to  be  performed  in 
the  application  code.  Additionally,  a  graphic  interface  was  not  possible. 
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In  comparison  to  other  VAX  languages.  VAX  Lisp  was  slow  and  consumed  large  amounts 
of  space.  Additionally,  a  production  quality  version  of  ART  was  never  available  during  the  lime  AMPEE 
was  hosted  on  the  VAX;  expected  delivery  dates  slipped  continually,  and  the  versions  that  were  available 
were  not  error-free.  The  problems  experienced  with  ART  drove  the  AMPEE  implementation  deeper  into 
Lisp. 

The  main  advantage  of  the  VAX  implementation  of  AMPEE  was  that  it  was  hosted  on 
widely  available  hardware,  and  thus  could  be  used  by  a  larger  audience.  FMS  was  relatively  inexpensive, 
and  hence  was  not  a  deterrent  to  using  the  AMPEE  system. 

The  application  was  ported  to  a  Symbolics  during  CAMP-2.  A  major  factor  in  the  move 
from  the  VAX  platform  to  the  Symbolics  was  that  the  VAX  version  of  ART,  which  had  been  im¬ 
plemented  in  VAX  Common  Lisp,  was  being  re-hosted  in  C.  Inference  Corp.  intended  to  provide  a  subset 
of  Common  Lisp  that  could  be  called  from  ART.  but.  at  least  initially,  the  full  Lisp  functionality  that  the 
PCS  development  team  had  come  to  rely  on  would  not  be  available.  Thus,  a  decision  had  to  be  made  to 
either  port  to  the  C-based  version  of  ART  on  the  VAX,  or  port  to  a  Lisp  machine.  Porting  to  the  C-based 
version  would  require  rewriting  significant  quantities  of  Lisp  code  and  reworking  parts  of  the  application. 
Porting  to  a  Lisp  machine  would  require  redevelopment  of  the  user  interface,  but  presumably  a  complete 
implementation  of  ART  and  Lisp  would  be  available. 

The  port  from  the  VAX  to  the  Symbolics  required  not  only  a  complete  re-implementation 
of  (he  user  interface,  but  also  a  change  in  the  type  of  interface.  On  the  VAX,  the  forms  and  menus  were, 
for  the  most  part,  full  screen,  whereas  on  the  user  interface  developed  for  the  Symbolics  version  consisted 
of  pop-up  menus  and  forms  that  generally  filled  only  a  portion  of  the  screen. 

The  Symbolics  provided  a  good  development  environment.  Rapid  development  of 
prototype  interfaces  was  possible,  although  more  work  was  required  for  development  of  custom  inter¬ 
laces. 


(2)  Software 

Both  ART  and  Lisp  were  used  in  the  implementation  of  the  AMPEE  system.  ART  is  a 
programming  language  that  bears  some  resemblance  to  Lisp,  although  its  functionality  is  quite  different. 
As  mentioned  previously,  ART  is  an  expert  system  shell  intended  for  both  rapid  prototyping  and  produc¬ 
tion  of  expert  systems.  It  provides  a  means  of  capturing  knowledge  in  the  form  of  rules  and  schemata, 
and  a  means  of  invoking,  or  firing,  those  rules.  Although  the  basics  of  ART  are  fairly  simple  to  master,  it 
is  a  complex  tool.  Before  utilizing  such  a  tool,  it  would  be  beneficial  to  determine  which  of  its  features 
are  likely  to  be  needed,  and  determine  if  some  or  all  of  the  needed  features  are  available  in  a  simpler  and 
more  portable  package  or  language. 
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The  AMPEE  system  makes  only  limited  use  of  ART  functionality.  It  is  used  throughout 
the  AMPEE  system  for  data  structuring  (via  the  ART  schema  system),  and  within  the  Parts  Identification 
subsystem  for  consistency  checking  and  interface  control  (via  a  small  number  of  simple  forward-chaining 
rules),  and  for  display  of  the  missile  software  hierarchy  within  the  Missile  Model  Walkthrough  function. 
ART  provides  many  more  features  that  are  not  used  in  the  AMPEE  system,  such  as  backward  chaining 
rules  and  the  ability  to  explore  alternative  scenarios  via  the  viewpoint  mechanism. 

The  use  of  ART  for  system  development  imposes  a  number  of  limitations  on  deployment 
of  (he  final  system: 

•  Portability:  Although  it  is  available  on  a  fairly  wide  range  of  processors,  its  use  does  cut  down  on 
the  portability  of  the  application. 

•  Cost:  There  has  been  a  general  downward  trend  in  the  cost  of  high-end  experl  systems,  but,  the 
cost  of  such  a  tool  can  be  prohibitive  to  some  potential  users.  Some  vendors,  including  Inference, 
also  market  a  run-lime  system  separately  from  the  development  environment. 

•  Compatibility:  ART  must  stay  current  with  the  operating  system  under  which  the  user’s  machine  is 
running. 

The  PCS  team  developed  a  significant  quantity  of  reusable  software  that  was  used  through¬ 
out  the  AMPEE  system.  This  benefilled  not  only  the  developers  but  also  the  end-user.  Much  of  the 
reused  code  was  for  user  interface  functions,  thus  the  user  was  presented  with  a  more  uniform  interface 
than  might  otherwise  have  been  possible. 

(3 1  User  I  tiler  luce 

There  are  several  basic  types  of  data  entry/display  used  in  the  AMPEE  system  interface. 
They  are  explained  below. 

•  Single-choice  menu:  The  user  mouses  on  his  selection.  Most  of  these  menus  include  Pop  as  a 
selection;  this  allows  the  user  to  backup  to  previous  screens  to  examine  or  re-enter  data. 

•  Multiple-choice  menu:  These  are  two  part  menus,  whereby  the  user  selects  as  many  of  the  items  in 
the  choice  portion  of  the  menu  as  he  would  like,  and  then  selects  the  action  option  from  an  em¬ 
bedded  menu  The  action  options  are  Do  It  (take  the  options  selected  by  the  user),  None  (no 
options  desired).  All  (select  all  of  the  options),  and  Quit  (exit  this  screen). 

•  Fill-in-the-blank  field:  The  data  type  of  the  response,  or  a  default  value  is  generally  displayed  in 
the  field.  The  user  mouses  on  the  response  area  for  the  field,  enters  a  value,  and  presses  the  tenon 
key  to  proceed  to  the  next  field.  If  the  user  is  unable  to  mouse  on  a  field,  it  is  not  changeable. 

•  Multiple-choice  field:  All  of  the  options  are  displayed  to  the  user;  he  can  make  or  change  a 
selection  by  mousing  on  item.  Default  values  are  displayed  in  bold-face  type. 
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•  Display-only  form:  These  are  used  lo  provide  instructions,  or  to  display  information  to  the  user  that 
he  is  unable  to  alter. 

•  Scrollable  Itsl/menu:  This  is  a  list  of  data  that  may  be  more  than  one  windowful  in  length.  It  may 
be  scrolled  by  clicking  left  or  right  alter  the  scroll  arrows  arc  visible.  The  scroll  arrows  can  be 
made  visible  by  knocking  the  mouse  arrow  into  (he  left  margin.  For  menus  of  this  type,  the  next 
action  choices  (i.e.,  Done,  Pop)  generally  appear  as  menu  choices. 

•  Scrollable  form:  This  is  a  form  (hat  is  used  lo  display  a  list  of  data  items  or  text  that  may  be  more 
Ilian  one  windowful  in  length.  The  user  may  scroll  either  by  using  the  scroll  key  or  the  mouse.  At 
the  bottom  of  the  form  are  two  option  boxes.  Done  and  Pop.  To  exit  from  this  type  of  form,  the 
user  must  mouse  on  one  of  these  two  boxes.  If  more  mode  is  in  use,  the  user  must  scroll  past  all  of 
the  more  prompts  before  his  choice  of  Done  or  Pop  will  be  processed. 

•  List-inpul  form:  This  type  of  form  allows  the  user  lo  provide  one  or  more  values  of  a  particular 
type.  The  user  is  prompted  for  only  one  item  at  a  time.  Data  is  entered  by  mousing  on  the  prompt, 
supplying  a  value,  and  pressing  the  return  or  end  key.  Another  prompt  line  will  appear.  To 
terminate  processing  the  user  can  either  mouse  on  the  end  option  at  the  bottom  of  the  form,  or  press 
the  end  key.  In  general,  a  user  can  pop  from  this  type  of  form  by  entering  pop  on  the  last  prompt 
line.  To  delete  entries,  the  general  procedure  requires  the  user  to  mouse  on  the  entry  to  be  deleted, 
and  then  enter  nil.  Specifics  may  vary  somewhat  from  form  lo  form. 

I).  Paris  (  alalog 

The  basic  goals  of  a  software  parts  catalog  are  to  facilitate  reuse  of  pre-built  software  parts, 
facilitate  configuration  control,  and  provide  a  foundation  for  a  parts  composition  system.  It  is  basically  a 
data  base  application,  although  the  AMPEE  Parts  Catalog  has  been  implemented  using  ART  schemata 
and  Lisp  in  order  to  provide  the  user  w  ith  a  single  integrated  parts  composition  system. 

ART  schemata  arc  used  to  capture  the  actual  catalog  data.  There  is  one  schema  for  each  catalog 
entry,  and  one  schema  slot  for  each  catalog  entry  attribute.  A  slot  is  comprised  of  a  slot  name  and  a  slot 
value,  thus,  the  slot  name  represents  the  catalog  attribute  (e  g.,  date-of-last-change-of-enlry),  and  the  slot 
value  represents  the  attribute  value  for  a  particular  catalog  entry  (e.g.,  12-02-87). 

Some  of  the  catalog  entries  arc  textual,  therefore,  their  value  is  not  actually  stored  in  the  catalog 
schema.  Textual  attributes  are  used  to  capture  attribute  values  that  are  of  indeterminate  length.  Their 
actual  value  is  stored  in  a  file,  and  the  name  of  the  file  is  stored  in  the  schema  slot  associated  with  that 
particular  attribute.  When  a  user  wants  to  view  a  textual  attribute,  the  contents  of  the  file  are  fetched  and 
displayed.  When  textual  attributes  arc  added  or  modified,  the  AMPEE  system  user  is  put  into  an  editor. 
Deletes  of  textual  attributes  do  not  physically  take  place  until  the  user  exits  the  AMPEE  system  and 
confirms  that  he  wants  the  catalog  changes  to  be  saved. 

The  remainder  of  the  Parts  Catalog  subsystem  is  implemented  using  Lisp.  The  ART  data 
structures  are  accessed  via  Inference-provided  Lisp  functions.  This  subsystem  also  makes  use  of  an  editor 
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for  the  entry  of  information  for  textual  attributes.  Additionally,  the  print  function  makes  use  of  a  com 
mercially  available  text  processing  program  to  formal  the  catalog  entries. 

There  are  several  deficiencies  in  the  current  implementation.  Among  them  is  the  fact  that  there 
can  be  as  many  as  fourteen  textual  attributes  provided  per  catalog  entry.  Access  to  textual  attributes  is 
relatively  slow  compared  to  access  to  other  attributes  because  the  request  must  go  through  the  file  system. 
The  file  system  can  also  become  cluttered  with  attribute  files,  particularly  if  there  is  a  minimum  si/e 
imposed  on  all  files  by  the  operating  system.  The  textual  attribute  files  also  contribute  significantly  to  the 
overall  time  needed  to  exit  from  the  AMPEE  system.  If  the  user  chooses  to  not  save  the  catalog  changes 
from  the  current  session,  (he  AMPEE  system  exit  routines  examine  the  attribute  files,  deleting  any  that 
were  created  during  the  current  session. 

Another  problem  with  the  current  implementation  is  the  amount  of  time  needed  to  load  the 
catalog  initially,  and  to  save  it  after  completing  a  session.  Both  limes  are  directly  tied  to  the  number  ol 
catalog  entries.  Perhaps  a  re-examination  of  what  is  cataloged  is  in  order. 

c.  Parts  Identification 

The  Parts  Identification  subsystem  is  the  only  portion  of  the  AMPEE  to  use  ART  for  anything 
more  than  data  structuring.  It  makes  use  of  both  simple  forward  chaining  rules  and  facilities  within  the 
ART  Studio.  The  ART  Studio  contains  several  functions  for  browsing  the  current  slate  of  an  ART 
knowledge  base,  including  one  that  permits  viewing  of  the  inheritance  network ;  it  is  this  function  that  is 
used  for  the  display  and  traversal  of  the  missile  models  in  the  Missile  Model  Walkthrough  function. 
Although  this  function  serves  its  purpose  in  a  prototype  implementation,  clarity  of  the  display  for  this 
application  is  less  than  optimal. 

d.  Component  Constructors 

Each  constructor  within  the  Component  Constructor  subsystem  incorporates  one  or  more  ART 
schemata  that  capture  the  requirements  needed  to  generate  a  specific  component  for  a  user.  These 
schemata  are  referred  to  as  requirements  sets',  they  are  accessed  by  Inference-provided  Lisp  functions  that 
are  called  from  within  the  constructor.  Storage  of  the  requirements  sets  allows  them  to  be  recalled  at 
some  future  session,  and  either  modified  or  used  as  is  to  generate  additional  components. 

3.  FUTURE  DIRECTIONS 

The  prototype  PCS  developed  under  CAMP  has  proven  that  tools  can  be  developed  to  facilitate  the 
use  of  reusable  software.  Development  of  this  prototype  has  pointed  out  both  potential  problem  areas 
within  the  current  implementation,  and  areas  for  further  development  and  investigation.  Listed  below  are 
some  areas  for  further  work/invesligation. 

•  Parts  Catalog 

-  Restructure  the  parts  catalog.  Currently,  almost  anything  can  be  cataloged;  this  has  not 
proven  to  be  necessary,  or  particularly  useful.  It  can  result  in  confusion  on  the  part  of  (he 
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user  when  he  is  confronted  with  1 100+  catalog  entries  when  there  are  only  about  450  parts. 
This  discrepancy  is  the  result  of  cataloging  specifications  and  bodies  separately,  and  of  also 
cataloging  encapsulating  packages  which  are  not  classified  as  parts  by  the  definition 
developed  during  CAMP- 2.  It  is  also  possible  to  catalog  generic  formal  parts  and  context 
clauses,  in  addition  to  generic  and  non-generic  package,  task,  and  subprogram  specifications 
and  bodies. 

Restructuring  the  catalog  could  benefit  the  Parts  Catalog  in  another  area  —  within  the  Ex¬ 
amine  Part  function.  This  function  allows  the  user  to  examine  the  source  code  for  the 
cataloged  entity.  If  the  entity  is  a  part  that  is  encapsulated  within  a  package,  the  user  is 
presented  with  the  entire  file  that  contains  the  particular  entity  of  interest  (the  user  does  have 
the  option  of  having  the  header  comments  stripped  out  of  the  file  before  it  is  displayed).  This 
can  be  both  an  annoyance  and  a  deterrent  to  use.'.  It  is  inconvenient  to  step  through  a  large 
file  to  find  a  deeply  embedded  entity.  Additionally,  it  can  be  confusing,  and  cause  the  user  to 
think  that  the  system  is  not  operating  correctly. 

-  It  might  be  beneficial  to  provide  the  user  with  functions  that  act  more  directly  on  the  part 
hierarchy.  Currently,  the  user  can  obtain  information  on  the  hierarchical  structure  of  lire  parts 
via  an  examination  of  the  built  from  and  used  to  build  attributes.  There  should  be  a  more 
straightforward  way  to  obtain  this  information  (perhaps  graphically). 

•  Parts  Identification 

-  Extract  the  essence  of  (he  Parts  Identification  functions  so  that  the  basic  mechanism  can  be 
applied  to  domains  other  than  those  covered  by  the  CAMP  work. 

•  Expand  the  missile  models  to  permit  finer  granularity  in  the  identification  of  parts  for  the 
user. 


-  Expand  the  knowledge  base  to  incorporate  more  domain  knowledge,  the  goal  being  the  iden¬ 
tification  ol  parts  that  can  be  used  to  build  needed  parts. 

-  Smooth  the  transitions  between  PCS  functions,  and  provide  greater  carry-over  between  them. 
•  Component  Constructors 

-  The  concept  of  component  constructors  is  a  valuable  one.  but  the  approach  to  implementation 
of  constructors  is  an  area  that  could  benefit  from  further  work.  The  approach  used  in  the 
AMPEE  system  tics  the  constructors  (for  complex  generic  parts)  intimately  to  parts  that  they 
utilize.  This  can  be  a  problem  if  the  parttst  on  which  the  constructor  is  based  change  in  areas 
that  are  relevant  to  the  production  of  code  by  the  constructor. 

An  alternative  that  bears  further  exploration  is  the  concept  of  a  constructor  constructor,  i.e..  a 
generalized  software  constructor  that  would  generate  specific  constructors.  One  way  to  do 
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this  would  be  by  embedding  commands  within  the  reusable  parts  themselves  that  would 
indicate  the  information  that  would  be  required  from  the  user  in  order  to  generate  the  tailored 
Ada  components  that  are  needed.  The  parts  could  then  be  run  through  a  preprocessor  to 
produce  (he  appropriate  user  queries.  Code  generators  and  facilities  to  permit  data  type 
definition  or  provision  outside  of  the  constructor  would  also  be  required.  In  essence,  this 
would  be  a  smarter  constructor,  where  less  of  the  information  is  hard-coded  in  the  constructor 
itself. 

•  General 

-  The  entire  AMPEE  system,  as  it  is  currently  implemented,  is  not  very  portable.  Although  it 
has  been  implemented  using  ART  and  Lisp,  the  majority  of  the  interface  is  implemented 
using  Symbolics  extensions  to  Common  Lisp.  Additionally,  the  use  of  ART  limits  the  poten¬ 
tial  users  to  (hose  who  have  a  compatible  version  of  ART  available  to  them. 

-  It  is  a  time-consuming  process  to  load  all  of  the  files  associated  with  the  AMPEE  system,  but 
certain  things  can  be  done  to  alleviate  this  problem.  Provided  the  user  has  sufficient  disk 
space  on  his  machine,  he  can  load  all  of  the  AMPEE  system  files,  and  create  a  file  that 
captures  the  current  machine  environment;  it  is  then  possible  to  avoid  loading  all  but  the 
user-changeable  AMPEE  system  files  each  time  the  user  wants  to  run  the  AMPEE  system. 
The  user-changeable  files  include  the  catalog  itself,  and  the  collection  of  requirements  sets 
created  by  the  user.  Both  of  these  files  can  be  updated  by  the  user,  therefore,  it  is  not 
recommended  that  they  be  made  a  part  of  the  environment  that  is  saved  (i.e.,  they  should  be 
loaded  each  time  the  user  starts  a  new  session.  The  extent  of  the  inconvenience  of  doing  this 
is  somewhat  dependent  upon  the  amount  of  memory  that  the  user  has  on  his  machine.  In  the 
AMPEE  system  development  environment,  loading  the  catalog  look  in  excess  of  fifteen 
minutes  (note  that  load  time  is  also  dependent  upon  the  number  of  catalog  entries). 

-  Response  time  is  another  potential  problem  area.  Users  have  been  conditioned  to  expect  a 
fairly  rapid  response  when  interacting  with  a  computer.  Some  of  the  items  that  factor  into 
AMPEE  system  response  time  are  the  location  of  the  files  that  are  accessed  (i.e.,  is  (here 
activity  across  die  network  or  are  all  of  the  required  files  resident  on  the  host  machine),  the 
number  of  catalog  entries  (for  various  AMPEE  Parts  Catalog  functions),  whether  or  not  the 
underlying  Lisp  code  has  been  compiled  or  r.ot.  and  the  amount  of  memory  on  the  host 
machine.  The  AMPEE  system,  as  it  is  currently  implemented,  can  leave  the  user  hanging 
while  various  user  requests  are  fulfilled. 

-  Another  area  that  could  be  improved  to  enhance  usability,  is  the  inlerconneclivily  of  AMPEE 
system  functions.  Although  there  is  some  carry-over  between  functions,  it  is  limited,  c.g., 
there  is  carry-over  from  the  catalog  search  function  to  other  catalog  functions  that  operate  on 
existing  catalog  entries. 
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SECTION  V 


THE  ADA  lan<;ua<;e  and  software  reusability 

Support  for  reusability  has  been  a  key  goal  of  'he  Ada  language  since  its  development  begnn  In  (he 
1970's.  Reusability  includes  (he  ability  to  transport  code  between  different  machines  and  the  ability  to 
transport  code  between  applications.  Standardization  on  a  single  language  specification  and  prohibition  of 
modifications  to  create  subsets  or  supersets  of  the  language  have  largely  achieved  the  first  component. 
Complete  Ada  applications  have  been  transported  between  widely  disparate  machines,  with  minimal 
changes  to  the  source  code.  The  success  of  this  type  of  reusability  is,  of  course,  limited  by  machine 
dependencies  of  the  code  and  the  type  of  application  involved. 

For  reusability  to  truly  succeed.  Ada  code  must  be  transportable  not  only  between  machines,  but  also 
between  applications.  While  there  have  been  successful  cases  of  this  type  of  reusability,  the  CAMP 
project  has  concluded  that  portions  of  the  current  Ada  standard  inhibi1  ‘he  ability  to  transport  and  reuse 
code  between  applications.  These  conclusions  arc  based  on  problems  ncovered  during  (lie  implemen¬ 
tation  of  the  CAMP  parts  and  the  1 1th  Missile  Application;  therefore,  the  problems  are  seen  as  valid 
issues  which  must  be  addressed,  and  not  as  conjectural  speculation  on  potential  use  of  the  language  or  as 
the  result  of  a  specific  effort  to  find  fault  with  the  language. 

Ada  language  issues  raised  during  CAMP  include  language  definition  and  language  restrictions.  In 
some  cases,  the  standard  leaves  to  the  compiler  implementor  key  decisions  which  can  affect  the  ability  of 
a  compiler  to  handle  code  developed  for  reuse.  Furthermore,  as  discussed  in  Section  VII,  the  Ada  valida¬ 
tion  capability  does  not  adequately  test  all  of  the  standard  Ada  features  which  are  required  for  implemen¬ 
tation  of  reusable  software.  Additionally,  the  standard  lacks  certain  specific  features  which  could  further 
enhance  reusability,  especially  for  the  design  of  special  interfaces. 

This  section  of  the  report  discusses  areas  where  Ada's  support  for  reusability  of  code  between  ap¬ 
plications  can  be  improved;  examples  from  CAMP  implementations  will  illustrate  (he  problems.  Recom¬ 
mendations  arc  also  made  for  implementing  these  improvements  as  a  part  of  the  Ada  9X  revision  process. 

I.  SEPARATE  COMPILATION  AND  (JENERIC  UNITS 

Ada  generic  units  form  the  key  constructs  of  reusable  software.  Sections  II  and  VI  of  this  report 
discuss  the  use  of  generic  units  in  CAMP  parts  development  and  in  the  CAMP  development  methodol¬ 
ogy. 

Part  of  the  (  AMP  development  methodology  includes  the  separate  compilation  of  generic  subunits. 
This  approach  facilitates  development  and  maintenance  by  reducing  the  size  of  compilations  and  the 
requirements  for  recompilation  should  subunits  change.  This  approach  is  also  consistent  with  the  goal  of 
Ada  to  support  modularity. 
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The  development  of  reusable  software  based  on  generic  units  is  impeded  by  ambiguity  in  the  Ada 
language  standard.  Support  for  separate  compilation  of  generic  units  is  not  a  required  Ada  feature; 
therefore,  it  is  not  addressed  in  the  Ada  Compiler  Validation  Capability  (ACVC)  tests.  The  exact  state¬ 
ment  on  this  issue  occurs  in  Section  10.3,  Paragraph  9  of  the  Ada  Reference  Manual: 

"An  implementation  may  require  that  a  generic  declaration  and  the  corresponding  proper  body  be  part  of 
the  same  compilation,  whether  the  generic  unit  is  itself  separately  compiled  or  is  local  to  another  compila¬ 
tion  unit.  An  implementation  may  also  require  that  subunits  of  a  generic  unit  he  part  of  the  same 
compilation."  (Reference  8) 

This  statement  is  somewhat  ambiguous.  An  implementor  could  provide  a  compilation  system  which 
would  require  that  an  entire  package  be  placed  in  one  compilation.  Since  on  most  systems  a  compilation 
would  correspond  to  a  file,  the  file  would  contain  the  main  unit  and  unit  body  plus  all  subunits,  where  the 
unit  is  a  generic  package  or  subprogram,  or  any  combination  of  nested  packages  or  subprograms  within 
the  main  unit.  Any  change  anywhere  within  the  unit  would  require  recompilation  of  the  entire  unit  and 
body. 

Tlte  effect  of  this  requirement  would  be  disastrous  for  the  developers  of  a  reusable  software  library, 
such  as  the  CAMP  parts  library.  Figure  35  illustrates  potential  compilation  structures  for  a  simple  pack¬ 
age  encapsulating  two  generic  units.  (Note:  This  is  an  extremely  simple  case;  generally,  library  packages 
will  be  far  more  complex.  Also,  the  compilation  system  assumed  here  will  perform  recompilations, 
whether  or  not  units  have  changed.  More  sophisticated  systems  could  permit  incremental  compilation, 
which  would  only  affect  units  which  actually  require  recompilation.) 

•  Compilation  1  is  the  most  desirable  structure,  allowing  specifications,  bodies,  and  separate  units  to 
be  physically  located  in  separate  source  code  files.  This  structure  supports  case  of  development  and 
maintainability  through  separate  compilation  of  specifications  and  bodies. 

•  Compilation  2  allows  the  specification  to  be  located  in  a  separate  file,  but  requires  all  bodies  to  be 
located  in  the  same  source  code  file.  This  structure  increases  compilation  and  maintenance  time, 
but  has  no  affect  on  package  use. 

•  Compilation  3  has  the  same  result  as  Compilation  2.  This  structure  would  be  required  by  a  system 
that  did  not  permit  separate  subunits  of  a  generic  unit. 

•  Compilation  4  requires  a  specification  and  all  corresponding  bodies  to  be  located  in  the  same 
source  code  file.  This  structure  requires  complete  recompilation  of  the  specification  and  body 
whenever  any  part  of  B  or  C  changes.  In  addition,  because  units  which  import  A  are  rendered 
obsolete  by  the  recompilation  of  A.  the  importing  units  have  to  be  recompiled,  as  well. 

•  Compilation  5  does  not  make  use  of  packaging  and.  therefore,  each  of  the  units  can  be  located  in 
separate  source  code  files.  This  obviates  (he  need  for  extensive  recompilation.  Only  B  or  C  need  to 
be  recompiled  if  they  change,  and  any  units  importing  the  changed  unit  also  require  recompilation. 
However,  the  library  would  become  unmanageable  because  of  the  number  of  units. 

For  the  CAMP  library,  the  requirement  to  structure  compilations  according  to  Compilation  4  would 
typically  mean  recompilation  of  from  500  to  2000  lines  of  code,  depending  on  the  specific  unit,  any  time 
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Figure  35.  Ada  Generic  Compilations 

an  encapsulated  unit  was  changed.  If  specifications  and  bodies  must  be  in  a  single  compilation,  the  entire 
CAMP  software  library  could  potentially  be  affected  as  a  result  of  a  single  change  in  the  bCKtv  of  a  basic 
unit.  Compilation  5  would  split  up  large  units  into  small  constituents;  however,  this  would  require  mas¬ 
sive  context  clauses  and  would  enlarge  the  already  complex  CAMP  configuration  management  task. 
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For  users  of  ;i  reusable  Ada  software  library,  the  compilation  restriction  would  be  equally  serious.  If 
the  specification  to  a  library  package  changes  for  any  reason,  all  software  dependent  on  that  package, 
would  have  to  be  recompiled.  It  is  hoped,  however,  that  changes  to  a  specification  in  a  reusable  library 
would  be  extremely  rare.  However,  if  an  Ada  compilation  system  required  that  the  specification  and  hcxly 
of  a  generic  unit  be  in  a  single  compilation,  as  in  Compilation  4.  a  change  to  a  single  statement  in  the 
body  would  require  recompilation  of  the  specification  as  well  The  resulting  recompilations  could  ripple 
through  the  user's  system  and  require  extensive,  if  not  complete,  recompilation  of  the  user's  software. 

The  ambiguity  of  the  standard  in  this  area  also  permits  implementors  to  exaggerate  their  claims 
about  their  compiler.  Because  no  standard  on  separate  compilation  of  generic  units  exists,  an  implemen¬ 
tor  can  claim  support  for  the  feature,  yet  may  have  almost  no  support  beyond  separating  specification  and 
body  into  two  separate  compilations.  Attempts  to  separately  compile  units  beyond  this  level  can  result  in 
any  number  of  compiler  errors,  as  reported  in  Section  VII.  The  fact  that  nearly  every  implementor  does 
claim  support  for  this  feature  indicates  that  it  is  a  feature  desired  by  most  compiler  users. 

The  CAMP  experience  establishes  the  nce^  for  making  separate  compilation  of  generic  units  a  re¬ 
quired  feature  of  Ada.  In  order  to  provide  continued  support  for  software  reuse,  the  9X  revision  must 
consider  this  need  Numerous  tests  of  support  for  the  facility  were  developed  during  the  CAMP-2 
project;  these  tests  can  be  used  to  measure  the  claims  ol  compiler  implementors  in  the  interim  These 
tests  form  part  of  the  CAMP  Armomcs  Benchmarks  described  in  Volume  III  of  this  icport. 


2.  OPT  IMIZATION 

The  success  of  Ada  requires  the  availability  of  optimizing  compilers.  Without  significant  optimiza¬ 
tion.  Ada  will  never  achieve  the  throughput  or  memory  restrictions  imposed  by  requirements  for  most 
embedded  software  systems  Additional  optimization  to  address  generic  units  will  also  be  needed  be¬ 
cause  of  the  heavy  use  made  of  generic  units  in  reusable  software. 

Of  particular  concern  to  developers  of  optimizing  compilers  is  the  issue  of  optimization  across  unit 
boundaries.  Several  optimization  issues  must  be  addressed: 

•  How  will  an  individual  user  utilize  the  objects  in  a  package'.' 

•  Will  all  users  of  the  same  package  require  the  same  optimizations? 

•  Where  another  unit  imports  objects  from  the  original,  what  effect  will  use  of  the  objects  of  the 
original  unit  have  on  optimization  of  the  user  s  objects  ' 

With  generic  units  these  requirements  become  ev  en  more  difficult  to  address.  By  design,  the  generic 
unit  must  meet  the  needs  of  numerous  end-users.  These  needs  must  be  tailored  by  data  structures  and 
specific  sets  of  operations  on  the  data  While  the  CAMP  parts  have  been  designed  to  address  many  ol  Un¬ 
typical  efficiency  needs  of  embedded  systems  to  limit  or  even  eliminate  inefficiency  due  to  reusability, 
the  success  of  reusability  itself  depends  on  compilers  optimizing  the  final  code  once  the  generic  unii  is 
instantiated 

Another  lorm  of  optimization  is  the  generation  of  code  based  on  the  actual  parameters  in  a  generic 
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instantiation.  Presently,  the  actual  parameters  do  not  affect  the  code  generation;  compilers  either  generate 
new  code  for  each  instantiation,  even  if  actual  parameters  are  the  same,  or  they  generate  only  one  body 
regardless  of  the  number  of  instantiations.  In  the  former  case,  size  can  grow  even  though  each  instance  is 
a  mere  copy.  In  the  latter,  the  compiler  must  generate  additional  code  to  handle  specific  calls  to  each 
instance.  The  additional  code  will  be  generated  even  if  (here  is,  in  fact,  only  a  single  instantiation. 

Figure  36  shows  these  two  methods  plus  a  hybrid  method  that  overcomes  the  deficiencies  of  the 
other  two.  This  different  body  method  will  perform  three  types  of  instantiations: 
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Figure  36.  Methods  of  Generic  Instantiation 


•  Generate  multiple  bodies  for  truly  distinct  instances 

•  Generate  a  single  body,  with  no  additional  case-specific  code,  if  there  is  only  a  single  instantiation 

•  Generate  a  single  body  lor  multiple  instantiations  using  the  same  actual  parameter  types 

This  approach  assumes  global  optimization  across  packages.  Because  it  is  not  generally  possible  to 
know  in  advance  how  a  potential  user  would  use  the  generic  unit,  the  optimization  must  occur  following 
all  instantiations. 

The  CAMP  parts  library  provides  compiler  developers  with  an  excellent  set  of  examples  for  dealing 
with  optimization  issues.  Within  the  parts  structure  itself,  there  is  extensive  reuse  of  objects  between 
parts.  Optimization  addressing  the  needs  of  the  parts  themselves  could  address  many  concerns  that  arise 
in  the  development  of  a  library  of  parts.  The  1 1th  Missile  Application  demonstrates  the  use  of  parts  in 
building  an  application,  and  can  provide  guidance  to  compiler  developers  in  meeting  the  needs  of  the 
end-user  of  (he  parts. 
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3.  TASK  PRIORITIES 


Task  priorities  are  used  to  indicate  the  relative  priority  of  one  task  over  another  in  the  allocation  of 
system  resources.  In  general,  those  things  that  have  to  he  done  quickly  or  on  a  precise  time  schedule  are 
given  the  highest  priority.  For  example,  within  the  1 1  lit  Missile  Application,  the  interrupt  handlers  which 
process  messages  to  and  from  (he  1553B  bus  arc  given  (lie  highest  priority  in  the  system  because  the 
interrupts  can  come  as  often  as  every  few  hundred  microseconds,  and  each  must  be  handled  before  the 
next  one  comes  in. 

Tasks  with  low  priority  generally  occur  relatively  infrequently  and  do  not  have  tight  timing  con¬ 
straints.  For  example,  within  the  1 1th  Missile  Application,  the  IS  A. Monitor  queries  the  ISA  status  every 
minute.  If  (he  actual  delay  between  queries  is  62  seconds  instead  of  60,  no  major  problems  will  result. 
Similarly,  the  Status_Generator  runs  twice  a  second  to  generate  an  operator  status  display.  If  one  or  more 
runs  get  skipped,  there  is  no  adverse  effect  on  the  system.  Neither  of  these  tasks  can  be  allowed  to  delay 
the  completion  of  the  higher  priority  tasks. 

Currently,  the  Ada  language  standard  requires  that  task  priority  be  established  by  a  static  value,  thus, 
not  only  must  the  priority  be  fixed,  it  must  be  fixed  by  a  simple  constant  expression.  Reusability  could  be 
enhanced  by  the  following  changes: 

•  For  tasks  declared  within  a  generic  package,  allow  task  priority  to  be  specified  as  a  generic 
parameter.  This  would  have  been  useful  for  the  1553B  bus  interfaces  of  the  lllh  Missile  Applica¬ 
tion.  One  of  the  1750A  processors  has  two  bus  interfaces;  the  code  for  the  interfaces  was  identical 
except  for  task  priorities  and  command  port  addresses. 

•  Allow  task  priorities  to  be  specified  dvnamically.  This  would  be  particularly  useful  for  multi- 
window  user-interface  software,  in  which  an  instantiation  of  a  generic  task  is  created  for  each 
window.  The  task  that  is  cuirenlly  interacting  with  the  user  would  then  be  able  to  elevate  its 
priority  (or  have  it  elevated). 

4.  ADDRESS  CLAUSES 

Address  clauses  allow  objects  to  be  tied  to  specific  addresses  (for  example,  I/O  ports).  Currently,  (he 
Ada  language  standard  requires  that  an  address  clause  be  "immediately  within  the  same  declarative  part, 
package  specification,  or  task  specification"  as  the  object  it  references.  The  address  is  required  to  be  a 
simple  expression. 

Reusability  would  be  enhanced  by  (he  following  changes: 

•  Allow  addresses  to  be  specified  as  a  generic  parameter.  As  noted  in  (he  previous  section,  the 
1553B  bus  interfaces  in  the  I  lilt  Missile  Application  were  identical  except  for  task  priorities  and 
command  port  addresses. 

•  Allow  the  address  of  a  specification  item  to  be  specified  in  the  body.  This  would  allow  a  package 
(or  task)  specification  to  have  multiple  bodies,  with  each  body  mapping  items  declared  in  the 
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specification  to  addresses  as  required.  Since  the  specification  would  not  be  affected,  the  code  using 
the  package  (or  task)  would  not  have  to  be  recompiled. 

5.  IMPLEMENTATION  OF  REDUCED-PRECISION  FLOATING  POINT  TYPES 

The  use  of  strong  data  typing  in  real-time  embedded  applications  supports  reusability  but  at  a  cost  to 
(he  developer  and  user  of  reusable  software  in  these  applications.  As  detailed  in  Section  VI,  these  applica¬ 
tions  require  large  numbers  of  mathematical  operators  for  the  different  types  of  data.  This  subsection 
discusses  the  inadequacy  of  the  Ada  standard  in  addressing  the  needs  of  applications  with  large  numbers 
of  operators. 

The  application  developer  has  two  choices  in  maintaining  strong  data  typing  in  a  real-time  embedded 

system: 

•  Create  a  few  base  types  and  declare  subtypes.  The  strong  data  typing  results  from  establishing  and 
enforcing  rules  in  the  use  of  the  subtypes.  This  implicit  form  of  strong  data  typing  must  be  im¬ 
posed  because  there  will  be  no  matching  between  parameters  in  assignments  or  subprograms  other 
than  that  of  range.  If  two  objects  have  the  same  base  type  they  can  be  treated  as  if  they  are  of  the 
same  type,  unless  an  object  assignment  is  out  of  range. 

The  lack  of  strong  type  checking  simplifies  the  end-user’s  job.  The  user  does  not  have  to  create 
large  numbers  of  operators  to  deal  with  the  subtypes  unless  operations  are  between  different  base 
types;  however,  the  user  must  understand  that  any  operations  on  subtypes  will  be  those  of  the  base 
type.  For  example,  a  subtype  which  restricts  the  range  and  precision  of  a  double  precision  base  to 
single  precision  will  have  the  same  operators  as  the  base  type  so  the  user  will  get  double  precision 
operators  on  single  precision  subtypes. 

•  Create  a  few  parent  types  and  declare  derived  types.  Derived  types  prevent  any  operations  between 
types  other  than  those  explicitly  declared  or  existing  as  derived  operations.  The  strong  data  typing 
rules  are  explicitly  enforced.  The  user  of  derived  types  must  create  his  own  operators  for  operations 
between  these  types,  whether  or  not  they  are  derived  from  the  same  parent. 

CAMP  supports  the  user  of  derived  types  by  supplying  many  of  the  operations  between  data  types 
which  arc  likely  to  occur  in  applications  using  the  CAMP  parts.  This  reduces  the  need  for  user- 
created  operators,  assuming  the  CAMP  operators  meet  his  requirements.  The  CAMP  parts  cannot, 
however,  address  the  low-level  operator  needs  of  all  end-users.  In  particular,  real-time  embedded 
applications  frequently  mix  single  and  double  precision  data  types  for  similar  objects.  For  ex¬ 
ample,  there  may  be  multiple  measurements  of  acceleration,  e.g.,  gravitational  acceleration,  missile 
vertical  acceleration,  missile  horizontal  acceleration.  These  objects  may  differ  in  precision;  thus,  to 
strictly  maintain  strong  data  typing,  they  should  be  of  different  types,  though  all  are  derived  from 
(he  same  parent. 

In  general,  CAMP  parts  do  not  account  for  this  strong  data  typing  where  precision  is  the  discriminat- 
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ing  feature.  It  is  a  problem  both  for  subtypes,  where  the  user  obtains  the  same  operator  regardless  of  the 
precision  of  the  subtype,  and  for  derived  types,  where  the  user  is  required  to  create  operators  which  the 
CAMP  parts  cannot  provide.  To  explicitly  support  derived  types  of  all  precision  would  require  an  explo 
sion  in  the  number  of  generic  formal  types  and  generic  formal  subprograms,  plus  the  number  of 
predefined  types  and  operators  to  be  used  as  actual  parameters  in  instantiations.  The  user,  in  this  case, 
must  either  use  subtypes  and  enforce  strong  data  typing  implicitly  through  strict  management  of  the 
development  process,  or  must  create  his  own  operators. 

Compilers  may  not  allow  a  choice  of  operators  for  derived  types.  The  compiler  can  legally  generate 
code  such  that  all  numerical  operations  result  in  the  generation  of  code  of  the  highest  precision  for  the 
target  machine.  Hie  Ada  standard  places  conformance  requirements  on  the  final  result  of  a  computation, 
not  on  intermediate  results. 

Ada  does  not  provide  any  support  for  the  use  of  subtypes  to  account  for  different  precisions.  Math¬ 
ematical  operations  on  a  subtype  are  exactly  those  of  the  base  type  (Reference  8,  pp  3-23,  Section  3.5.3, 
paragraph  16).  In  order  to  modify  the  precision  of  the  operation  generated  for  the  target,  the  user  must 
perform  explicit  type  conversions.  Of  course,  this  will  work  only  if  the  compiler  generates  internal  math¬ 
ematical  operations  based  on  the  precisions  of  the  types. 

An  obvious  solution  to  this  problem  is  to  eliminate  the  restriction  from  the  Ada  standard  that  opera¬ 
tions  on  subtypes  be  those  of  the  base  type.  It  would  be  possible  for  a  compiler  to  recognize  subtype 
attributes  and  generate  code  to  match.  For  exam  ple,  Figure  37  shows  a  double  precision  base  type  and 
double  and  single  precision  subtypes.  Ada  will  permit  mixing  of  these  types  in  operations  but  all  opera¬ 
tions  will  be  double  precision.  The  recommended  language  change  would  generate  code  such  that  the 
operations  follow  the  precision  of  the  result  type. 

package  Baaic_Typea  la 

Double  :  constant  :*  9; 

Single  :  constant  :■  6; 

type  Double__Precisions  la  digits  Double; 

subtype  Single_Precia ions  is  Double_Precl*lona  digits  Slngle; 

--  --  Double  precision  operations 

function  (Left;  Double_Preci#iona ; 

Right:  Single  Precisions)  return  Double__Preclsions; 

--  --  Single  precision  operations 

function  (Left:  Doubleup  reel a ions ; 

Right;  Single_Preciaiona )  return  Slngle__Preclsiona; 

end  Basic_JTypea ; 


Figure  37.  Subtypes  Should  Support  Reduced-Precision  Operations 
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6.  PROCEDURAL  DATA  TYPES 


Al  the  present  time.  Ada  has  no  facility  for  defining  procedural  data  types.  As  a  result,  subprograms 
(procedures  and  functions)  cannot  be  passed  as  parameters.  There  are,  however,  two  contexts  in  which 
this  capability  is  not  only  desirable,  but  practically  indispensable.  The  first  context  is  state  machine 
applications  where  the  states  and  transitions  are  either  dynamic  or  unknown  at  compile-time;  the  second 
context  is  that  of  artificial  intelligence  (AI)  applications. 

In  the  stale  machine  context,  the  user  often  wishes  to  be  able  to  dynamically  control  states  of  an 
application,  adding  or  subtracting  states  as  needed.  The  inability  to  define  procedural  data  types  presents  a 
considerable  handicap  since  this  requires  all  procedures  to  be  known  at  compile-time;  any  time  a  new 
state  and  transition  needs  to  be  added  or  deleted,  the  whole  state  machine  must  be  recompiled.  The  ability 
to  pass  subprograms  as  parameters  would  allow  an  application  to  dynamically  specify  transi  ons  and 
actions  associated  with  new  states.  User  interface  systems  often  fit  this  category  of  applica' .  .is.  In  a 
finite  state  machine,  where  the  number  of  states  remains  fixed,  often  the  actions  associated  with  slates  or 
transitions  need  to  change  dynamically.  The  ability  to  pass  subprograms  would  make  possible  this  type 
of  dynamic  allocation  for  these  applications  as  well  as  in  more  general  state  machines. 

In  the  area  of  AI  systems,  the  ability  to  pass  subprograms  as  parameters  is  also  highly  desirable. 
Because  artificial  intelligence  applications  rely  heavily  on  the  ability  to  use  procedures  as  storable, 
denotable  objects''  (Reference  9).  the  lack  of  this  ability  in  Ada  considerably  diminishes  the  capability  to 
express  AI  paradigms. 

7.  DYNAMIC  BINDING  OF  BODIES  TO  SPECS 

Currently,  only  a  one-to-one  relationship  between  package  bodies  and  specifications  is  permitted  l  y 
the  Ada  language.  In  most  instances,  this  is  sufficient,  but  there  are  cases  where  a  many-to-one  relation¬ 
ship  would  be  useful.  This  would  allow  multiple  package  bodies  for  a  single  package  specification  to 
exist  simultaneously  in  the  same  Ada  library.  Which  body  should  be  used  by  the  compiler  for  code 
generation  would  be  specified  when  the  user  imported  the  package  via  a  with  statement. 

One  instance  where  this  would  be  useful  is  when  working  with  the  CAMP  Standard_Trig  package;  a 
partial  specification  for  the  Standard_Trig  TLCSC  is  shown  in  Figure  38.  This  package  defines  a  sv  t  of 
standard  trigonometric  operations  for  a  system.  In  order  to  implement  the  supplied  functions,  the  package 
body  of  Standard_Trig  instantiates  portions  of  the  Polynomials  package. 

Figure  39  contains  a  partial  package  specification  for  the  Polynomials  TLCSC.  This  package  con¬ 
tains  a  large  number  of  polynomial  solutions  to  various  transcend  er<-d  functions.  It  also  provides  access 
to  the  transcendental  functions  provided  by  the  VAX  Ada  environment. 

During  the  CAMP  parts  development  effort,  the  package  body  of  Standard_Trig  instantiated  portions 
of  (he  Polynomials. System_Functions  LLCSC  in  order  to  obtain  access  to  the  VAX-supplied  transcen- 
'  oital  functions  (see  Figure  40).  While  this  package  body  would  be  useful  for  anyone  doing  development 
using  VAX  Ada.  it  would  not  be  appropriate  for  an  application  designed  to  run  in  an  embedded  environ¬ 
ment.  A  modification  that  would  allow  this  part  to  be  used  in  an  embedded  environment  would  involve 
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generic 

typa  Angla  ia  digit®  <> ; 

typa  Trigjlatio  is  digit®  <>; 

Pi_Valua  :  in  Angla; 

packaga  3tandard_Trig  it 

typa  Radiana  is  naw  Angla; 

typa  Sin_Coa_Ratio  i®  naw  Trig_Ratio  ranga  -1.0  ..  1.0; 
typa  Tan__Ratio  ia  naw  Trig__Ratio; 

function  Sin  (Input  :  Radiana)  raturn  Sin_Coa_Ratio; 

function  Cob  (Input  :  Radiana)  raturn  Sin_Coa_Ratlo; 

function  Tan  (Input  :  Radiana)  raturn  Tan__Ratlo; 

and  Standard^Trig; 


Figure  38.  Partial  Standard_Trig  Package  Specification 


packaga  Polynomial®  ia 

packaga  Haatlnga  la 
ganarlc 

typa  Radiana  ia  digit®  <>; 

typa  Sin_Coa__Ratio  la  digit®  <>; 
packaga  Baatinga_Radian_Oparationa  ia 

function  Sin_R_4tarm  (Input  :  Radiana)  raturn  Sin_Coa_Ratio; 
function  9in_R_5tarm  (Input  :  Radiana)  raturn  Sin_Coa__Rat io; 
and  Baatlnga_Radlan_Oparationa; 

and  Haatlnga; 

packaga  Syatam_runctiona  ia 
ganarlc 

typa  Radiana  ia  digit  a  <>; 

typa  Sin_Coa_Ratio  la  digit®  <>; 
packaga  Radlan_Oparationa  la 

function  Sin  (Input  :  Radiana)  raturn  Sin__Coa_JRatio; 
and  Radian_Oparationa  ; 

and  Syatam_JTunctiona ; 
and  Polynomial®; 


Figure  39.  Partial  Polynomials  Package  Specification 

selecting  polynomial  solutions  from  the  Polynomials  TLCSC  and  instantiating  them  accordingly.  If  the 
application  required  the  selection  of  algorithms  for  multiple  precisions,  the  required  modifications  would 
be  more  extensive  since  the  Standard_Trig  package  has  been  designed  to  provide  overloaded  operations 
for  different  units,  but  r  I  for  different  precisions. 
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with  Polynomial*; 

package  body  Standard_Trig  1* 

package  Radian_Opns  is  new  Polynomials  .  Systam_runctlon*  .  Radi  an_Ope  rat  ion* 
(Radians  *>  Radians, 

Sin_Co*_Rat io  *>  Sin_Cos_Ratio)  ; 

function  Sin_R  (Input  :  Radians) 

return  Sin_Cos_Ratio  renames  Radi an_Opna . Sin; 

function  Sin  (Input  :  Radians)  return  Sin_Co*_Ratio  is 
begin 

return  Sin_R  (Input  *>  Input); 
end  Sin; 

end  3tandard_Trig, 


Figure  40.  System  Functions  Version  of  Standard_Trig  Package  Body 
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Under  (he  current  definition  of  the  Ada  language,  the  problem  of  modifying  the  Standard_Trig  pack¬ 
age  to  provide  trigonometric  functions  for  multiple  precisions  could  be  solved  in  one  of  the  following 
ways: 

1.  Duplicate  packages  could  be  provided  for  each  precision.  This  is  the  approach  that  was  taken  on 
(he  1 1  111  Missile  Application.  It  involved  duplicating  package  specification  code,  giving  each 
package  its  own  unique  name,  and  'hen  implementing  the  bodies  for  the  different  precisions  (see 
Figures  41  and  42).  This  method  has  the  disadvantage  of  requiring  the  creation  of  packages  which 
are  identical  except  for  their  names. 


with  Polynomial*; 

package  body  9tandard_Trig  la 

package  Radlana_Opna  la  new  Polynomials  .  Baatlnga  .  Haatinga_Radlan_Operation* 
(Radiana  »>  Radians, 

Sin_Co*__Ratlo  ■=>  gin_Cos_Ratio)  ; 
function  Sin_R  (Input  :  Radiana) 

return  SinCoa  Ratio  renames  Radiana  Opna . Sin  R_4T*rm; 
function  Sin  (Input  :  Radians)  return  Sin__Co*_Ratio  la 
begin 

return  Sin__R  (Input  *«>  Input); 
end  Sin; 

end  Standard_Trig; 


Figure  41.  Single  Precision  Version  of  Standard_Trig  Package  Body 


with  Polynomials; 

package  body  Standard_Trig  la 

package  Radiane_Opns  la  new  Polynomial*  .  Baatlnga  .  Haatinge_Radian_Operation* 
(Radiana  **>  Radians, 

Sin_Co*_Ratlo  ■>  Sin_Cos_Ratio)  ; 
function  Sin_R  (Input  :  Radians) 

return  Sin_Coa_Ratio  renames  Radiana_Opna  .  Sin_R__5Term; 
function  Sin  (Input  :  Radiana)  return  Sin_Coe_Ratio  is 
begin 

return  Sin_R  (Input  *=>  Input); 
end  Sin; 

end  Standard_Trig; 


Figure  42.  Extended  Precision  Version  of  Standard_Trig  Package  Body 


2.  The  package  specification  for  Standard_Trig  could  be  modified  to  allow  for  multiple  precisions  us 
shown  in  Figure  43.  This  method  is  less  desirable  than  Solution  1  because  it  requires  major 
modifications  to  the  package  specification,  as  well  as  creation  of  a  new  body. 

3  The  baseline  CAMP  Standard  Trig  package  could  be  modified  in  a  manner  similar  to  that  dis¬ 
cussed  in  Solution  2  and  shown  in  Figure  43.  This  approach  has  the  following  disadvantages: 

•  It  requires  the  user  to  instantiate  the  package  and  possibly  receive  code  for  multiple  preci¬ 
sions  even  if  only  one  precision  was  required. 
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9tn«ric 

typ«  Xngl#_Sing]«__Pr«ciflion  is  digits  <>; 

typs  Angls_Extsndsd_Prscision  is  digits  <>; 

typs  Trig  R*tio_Singls_Prsc.ision  is  digits  <>; 

typs  Trig_Ratio_Extsndsd_Pr«t1ciaion  is  digits  <>; 

Pi_Valus_SP  :  in  Angls_Slngl«_Pr«ci*ion; 

Pi  Vslus  EP  :  in  Ajigls_JCxt*nd«d__Pr«alslon; 

pscJcsgs  StandmrdJTrig  is 


typs  Radians  SP  is  nsw  Angl*_Singla  Precision; 

typs  Radians_EP  is  nsw  Angla_Extandad_Pracision; 

typs  Sin_Cos_Ratio_SP  is  naw  Trig_Ratio_Singla_Praciaion  ranga  -1.0  ..  1.0; 

typa  Sin_Coa__R*tio_EP  is  naw  Trig_Ratio__Extandad_Pracision  ranga  -1.0  ..  1.0; 


typs  Tan_Ratio_SP 
typs  Tan_Ratio_EP 


is  naw  Trig_Ratio 
is  naw  Trig_Ratio 


Singla_Pracision ; 
Extandad  Pracision; 


function  Sin  (Input 
function  Sin  (Input 


Radians  SP)  raturn  Sin__Coa_Ratio_SP; 
Radians_EP)  raturn  3in_Coa_Ratio  EP; 


function  Cos  (Input 
function  Cos  (Input 


Radians  SP)  raturn  Sin_Cos_Ratio_SP ; 
Radians  EP)  raturn  Sin  Cos  Ratio  EP; 


function  Tan  (Input  :  Radians_SP)  raturn  Tan_Ratio_SP; 
function  Tan  (Input  :  Radians_EP)  raturn  Tan_Ratio_J5P; 


and  Standard_Trig; 


Figure  43.  Multiple  Precision  Version  of  Slanilard_Trig  Package  Specification 

•  It  does  not  solve  the  problem  of  what  to  do  if  more  than  two  precisions  are  required. 

The  preferred  solution  would  permit  a  single  package  specification  to  have  multiple  bodies.  The 
Standard  Trig  package  specification  code  would  then  not  require  modification;  the  user  would  create 
multiple  bodies,  all  of  which  would  exist  in  (he  program  library  at  the  same  time,  and  then  specify  which 
body  was  to  be  used  at  the  time  the  Standard_Trig  package  was  imported.  This  approach  has  the  advan¬ 
tage  of  increasing  the  reusability  of  the  Slandard_Trig  package  specification  since  it  would  require  no 
modifications,  regardless  of  the  number  of  bodies  required.  It  also  decreases  the  effort  to  use  the  part. 


S.  SEPARATION  <)l  REPRESENTATION  CLAUSES 

Flexibility  and  ease  of  use  are  key  attributes  of  good  reusable  software.  Ideally,  the  design  of  a 
reusable  part  should  be  sufficiently  flexible  to  permit  tailoring  without  modification  of  the  source  code 
itself.  It  source  code  modifications  are  required,  modification  of  the  body  is  preferable  to  modification  of 
the  specification  since  this  increases  the  reusability  of  the  specification,  avoids  modification  of  the  exter¬ 
nal  interface  provided  by  Iht  specification,  and  potentially  eliminates  the  need  to  recompile  other  portions 
of  the  system  which  are  dependent  upon  the  modified  part.  One  aspect  of  tailoring  which  cannot  be 
accounted  for  through  good  design  is  the  need  for  representation  clauses. 

"Representation  clauses  specify  how  the  types  of  the  language  are  to  be  mapped  onto  the  underlying 
machine.  They  can  be  provided  to  give  more  efficient  representation  or  to  interface  with  features  that  are 
outside  the  domain  of  the  language  (for  example,  peripheral  hardware)"  (Reference  8,  pp  13-1).  One 


example  of  (he  use  of  representation  clauses  in  the  1 1th  Missile  Application  is  in  the  definition  of  mes¬ 
sages  sent  across  the  data  bus  and  in  size  specifications  for  objects  of  certain  types.  An  example  of  this  is 
shown  in  Figure  44  where  the  contents  and  storage  representation  of  a  BlM_Error_Message  are  defined. 
A  further  explanation  of  (he  contents  and  storage  representation  of  this  message  can  be  found  in  Table  6. 
The  current  definition  of  the  Ada  language  states  that  "a  representation  clause  and  the  declaration  of  the 
entity  to  which  the  clause  applies  must  both  occur  immediately  within  the  same  declarative  part,  package 
specification,  or  task  specification"  (Reference  8,  pp  13-1).  While  the  need  for  representation  clauses  can 
be  anticipated,  their  form  cannot  be  since  they  are  application-specific.  As  a  result,  whenever  a  user 
wishes  to  apply  a  representation  clause  to  an  entity  defined  in  the  package  specification  of  a  reusable  part, 
the  source  code  for  the  specification  must  be  modified. 

with  BIM_Intarf act; 
with  Bua_Tarminala  ; 
with  Rapraaantation_Paramatara  ; 

package  Bua_Ma*aagaa  la 

packaga  BI  ranamaa  BIM_Xntarfaca; 
packaga  BT  ranamaa  Bua^Tarmlnala; 
packaga  RP  ranamaa  Rapraaantation_Paramatara; 

typa  Dummy_Array  la  array  (BI .  Hord_Counta  ranga  <>)  of  BI .  DataJWorda  ; 

typa  Short_Boolaan  la  naw  BOOLEAN; 

for  Short_Boolaan' SIZE  uaa  1; 

typa  Short_Faat  la  naw  INTEGER  ranga  - <2**15)  ..  (2**15) -1; 

for  Short_raat' SIZE  uaa  16; 

BIM_Error__Hord_Count  :  conatant  BI  .Hord__Counta  :«  1; 

BIMJError_Dummy_Si*a  :  conatant  BI .  lford_Counta 

;  *  BI  .Maaaaga_jSiza_Vforda  - 
B IM_E r  ror_Wo  rd^Coun  t ; 

typa  BIM_Error_Maaaagaa  la 
racord 

Word_Count  :  BI .  W^rd_Counta  ; 

Sourca  :  BT .  Tarminala; 

Daatinatlon  :  BT.  Tarminala; 

Maaaaga_Numbar  :  BI  Maaaaga_Numbara ; 

Statua  :  BI .  9tatua__Worda ; 

Dummy  :  Dumny^Array  (1 .  .  BIM_Error_Dun»ny_Sira)  ; 

and  racord; 

for  BIM_Error__Maaaagaa  uaa 
racord 

Word_Count  at  0  *RP  .  Storaga_Unita_j>ar__Hord  ranga  0..15; 

Sourca  at  1  *RP  .  Storaga__Onita__par__Word  ranga  0..3; 

Daatinatlon  at  1  *RP .  Storaga_Onita_j>ar_lford  ranga  4..7; 

Maaaaga_Numbar  at  1  *RP .  Storaga_Unita_par_Nord  ranga  8..  15; 

Statua  at  2  *RP  .  Storaga_Onita_j>ar_lford  ranga  0..15; 

Dummy  at  3  *RR  .  Storaga_Onita_par_fford 

ranga  0 .  .BIM_Error_Duntny_Si*a  * 

RP . Maa  a aga_Ho  rd_S i z a - 1 ; 

and  racord; 
and  Bua_Maa aagaa ; 


Figure  44.  I  Ith  Missile  Application  Use  of  Representation  Clauses 


TABLE  6.  BIM_ERROR_MESSAGES  CONTENTS  AND  STORAGE  REPRESENTATION 


Message 

Component 

Description 

Storage 

Representation 

WorcM'ount 

Number  of  words  in  the  message 

Located  in  bits  0-15  of  the  word  offset  0 
words  from  the  beginning  of  the  data  struc¬ 
ture 

Source 

Where  the  message  came  from 

Located  in  bits  0-3  of  the  word  offset  1  word 
from  the  beginning  of  the  data  structure 

Destination 

Where  the  message  is  being  sent 

Located  in  bin  4-7  of  the  word  offset  1  word 
from  the  beginning  of  the  data  structure 

Mc*sngc_.Nun»her 

Used  lo  distinguish  between  messages  of  the 
same  type 

Located  in  bits  8-15  of  the  word  offset  1 
word  from  the  beginning  of  the  data  strur 
lure 

Si  at  us 

11k  error  itself 

Located  in  bits  0-15  of  the  word  offset  2 
words  from  the  beginning  of  the  data  struc¬ 
ture 

Dummy 

A  ’filler’  array  used  to  keep  the  overall  size 
of  all  messages  the  same 

Starts  in  bit  0  of  the  word  offset  3  words 
from  the  beginning  of  the  data  structure  and 
continues  for  the  number  of  words  required 
to  completely  fill  the  message  structure 

Allowing  representation  clauses  to  be  specified  in  a  package  body  for  entities  declared  in  the  pack¬ 
age  specification  would  increase  the  reusability  of  the  specification.  In  cases  where  the  reusable  software 
consists  of  only  the  package  specification  with  the  body  being  user-defined,  a  representation  clause  could 
be  defined  in  the  Ada  body  without  any  modifications  to  the  reusable  specification  code.  In  cases  where  a 
body  already  existed,  permitting  the  modification  to  be  made  to  the  body  instead  of  the  specification 
could  potentially  eliminate  flic  need  to  recompile  other  portions  of  the  system.  The  placement  of 
representation  clauses  in  package  bodies  would  be  consistent  with  the  specification  (Ada  data  structure) 
versus  body  (implementation)  split  which  exists  throughout  the  Ada  language. 


SECTION  VI 


PARTS  DESIGN  METHODOLOGY 

I.  DESIGN  REQUIREMENTS 

The  development  of  reusable  software  presents  the  designer  with  a  conflicting  set  of  design  require¬ 
ments.  In  addition  to  being  reusable  on  a  number  of  different  real-time  embedded  applications,  the  design 
of  reusable  parts  must  address  the  following  issues: 

•  Well-defined  interfaces 

•  Efficient  implementations 

•  Strong  data  typing  to  minimize  inappropriate  use 

•  Availability  of  mathematical  operations  on  different  data  types 

•  Simplicity  of  use 

These  conflicting  requirements  have  led  some  to  the  conclusion  that  "since  the  generality  needed  for 
flexibility  and  portability  will  increase  software  overhead  and,  consequently,  decrease  the  software’s  ef¬ 
ficiency  ...  it  is  very  difficult  to  construct  reusable  missile  software  that  is  still  viable.”  (Reference  10,  p 
105).  This  is  not  the  conclusion  from  the  CAMP  project. 

The  CAMP  project  developed  a  design  methodology  to  address  these  conflicting  issues  and  produce 
reusable  parts  for  missile  applications.  A  set  of  reusable  part  goals  —  flexibility,  efficiency,  ease  of  use. 
and  protection  against  misuse  —  form  the  basis  of  this  method.  Flexibility  is  the  extent  to  which  parts 
can  be  modified  or  tailored  to  the  specific  needs  of  an  individual  application.  Although  parts  may  be 
reusable,  if  they  are  not  flexible  and  easily  tailored,  then  the  cost  of  using  a  part  may  be  prohibitively 
large  and  it  may  be  less  expensive  to  develop  a  new  part  than  to  try  to  tailor  or  modify  an  existing  part. 
The  issue  of  efficiency  is  one  which  has  long  plagued  reusability:  the  contention  is  that  parts  which  are 
reusable  can  never  attain  the  required  efficiency  for  use  in  real-time  embedded  applications.  The  parts 
must  also  be  easy  to  use  because  difficulty  of  use  increases  cost  of  reuse  and  may  mean  that  the  part  will 
never  be  reused.  Protection  against  misuse  refers  to  providing  the  user  with  protection  from  choosing  the 
wrong  part  for  a  given  requirement  or  calling  the  part  with  improper  parameters.  The  use  of  the  Ada 
generic  feature  and  strong  data  typing  prevents  misuse  to  some  extent.  However,  there  are  other  features 
which  may  be  included  in  the  design  of  parts  to  guard  against  misuse. 

The  CAMP  design  methodology  meets  the  reusability  goals  and  supports  parts  which  are  well-tested 
and  may  be  used  off-the-shelf.  The  methodology  utilizes  several  of  Ada’s  special,  though  standard, 
programming  features,  including  derived  types  and  subprograms,  generic  instantiation  and  subprogram 
overloading  The  CAMP  team  believes  that  this  design  approach  will  be  equally  appropriate  for  non¬ 
missile  applications  outside  the  CAMP  domain. 
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2.  DESHJN  METHODS 


Six  methods  for  llie  design  of  reusable  pans  were  considered  on  the  CAMP  program.  Figure  45 
illustrates  these  methods.  In  discussing  the  competing  methods,  a  specific  CAMP  part  will  serve  as  an 
example  This  part,  Compute_Earth_Relative_Horizonial_Velocitics,  has  three  inputs: 

•  Nominal_Eas!_Velocity  (VEL^) 

•  NominaLNorth_Velocity  (VELnn) 

•  Wander_Angle  (WA) 

It  processes  these  inputs  through  the  following  equations: 

•  VELe  :=  VELne  *  cos  (WA)  -  VEL^  *  sin  (WA) 

•  VELn  :=  VELnn  *  cos  (WA)  +  VELne  *  sin  (WA) 
producing  the  following  outputs: 

•  Tme  East  Velocity  (  VELe) 

•  True  North  Velocity  (VELN) 


TYPELESS  APPROACH  OVERLOADED  APPROACH  GENERIC  APPROACH 


Figure  45.  Reusable  Parts  Methods 


The  compulations  perfonned  in  this  example  require  trigonometric  functions  on  Wander__Angle  plus 
multiplication  and  subtraction  operators.  In  addition,  the  multiplication  operator  must  perform  its  opera- 
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tion  on  data  of  different  types,  namely,  a  velocity  type  and  a  sine-  or  cosine-of-an-angle  type.  These 
mathematical  functions  must  also  he  provided  for  all  possible  combinations  of  data  types  for  velocities 
and  angles.  For  example,  if  velocity  is  measured  in  feel-per-second  and  angle  is  in  radians,  the  following 
mathematical  operations  are  required: 

•  Sine  and  cosine  operations  on  radians; 

•  Multiplier  for  feet-per-second  by  the  result  of  (he  sine  and  cosine  operations;  and. 

•  Subtractor  for  the  result  type  of  the  multiplier. 

The  discussion  will  explain  the  methods  for  parts  design  and  evaluate  (heir  effectiveness  with  regard 
to  the  following  four  evaluation  criteria: 

1.  Efficiency  and  appropriateness  of  the  interface; 

2.  Control  for  preventing  misuse; 

3.  Availability  of  needed  mathematical  operators  and  functions;  and, 

4.  Degree  to  which  the  user’s  job  is  simplified. 

Following  the  presentation  of  the  six  methods,  this  section  will  focus  on  the  method  chosen  on  the 
CAMP  program  for  parts  design,  and  the  implications  of  that  method  for  a  generalized  parts  development 
environment. 

a.  Ty  peless  Mel  hod 

The  tvpelcss  method  assumes  that  all  data  objects  and  actual  parameters  will  be  of  the  universal 
float  type.  The  benefit  of  this  approach  is  to  alleviate  the  need  for  special  mathematical  operators  and 
functions  since  they  are  already  defined  in  standard  packages.  The  severe  disadvantage  is  that  the  com 
piler  and  runtime  system  cannot  perform  type  checking  to  prevent  misuse  of  the  part. 

The  failure  of  an  SDI-related  experiment  in  1985  illustrates  the  problems  which  can  result 
without  strong  typing.  The  experiment  required  an  orbiting  receiver  to  track  a  ground-based  laser.  The 
transmitter  was  positioned  at  an  elevation  of  approximately  10000  feel  and  this  elevation  was  to  be 
entered  into  the  flight  computer  of  the  receiver's  orbiting  platform.  The  flight  computer  was  programmed 
to  accept  ground  elevation  in  nautical  miles  not  feet,  however,  so  when  10000  was  entered,  the  platform 
oriented  the  receiver  to  point  to  a  position  10000  miles  above  the  surface  of  the  earth,  exactly  1 80  degrees 
from  the  correct  location,  1 0000 feet  above  the  surface. 

Strong  typing  of  parameters  could  alleviate  this  problem.  Figure  46  illustrates  the  data  type  and 
object  declarations  which  would  apply. 
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typo  Nautieal_Mllaa  ia  digits  6; 

aubtypa  Ground_Elavation  ia  Nautlcal_Mllaa  ranga  -1.0  ..  6.0; 
Tran#mlttar_Elavation  :  Ground_Elavation; 

Figure  46.  Strong  Data  Typing  Example 


This  would  restrict  the  input  values  of  Transmitter_Elevation  to  a  reasonable  range  for  units  of 
nautical  miles. 

The  specification  shown  in  Figure  47  illustrates  the  typeless  method.  A  user  application  .access¬ 
ing  this  procedure  could  pass  any  object  of  the  type  float  as  actual  parameters.  The  compiler  could  not 
perform  type  checking  to  prevent  possible  type  mismatching  and  there  could  be  no  runtime  checking  to 
assure  correct  ranges  lor  the  actual  parameters.  This  method  produces  parts  which  are  easy  to  use,  but 
offers  no  protection  against  misuse. 


procedure  Compute_Earth_Relat  ive_Hori*ontal__Veloaitiee 

(Nominal  Eaat  Valocity 

in  rLOAT ; 

Nominal  North  Velocity 

in  TLOAT; 

Winder  Angle 

in  FLO  til ; 

Eaet_Velocity 

out  TLOAT; 

North_Valoc lty 

out  rLOAT); 

Figure  47.  Typeless  Method 


l».  Overloaded  Method 

To  allow  a  greater  choice  in  data  typing,  the  nvct loaded  method  provides  the  user  a  separate 
version  of  each  part  to  allow  for  the  different  combination  of  data  types  which  the  part  user  might  require. 
The  code  segment  shown  in  Figure  48  illustrates  the  overloaded  method  applied  to  the  example  when  the 
velocities  are  of  type  Feet_Per_Second  and  Meters_Per_Second  and  Wander_Angle  is  in  Radians. 


package  Overloaded  Method  ia 

procadura  Computu_Earth_Ralativa_Horirontal_Valocitlaa 

{Nominal__Eaat_Velocity 

in 

Foot  Far  Sncond; 

Nominal  North  Velocity 

in 

Feet  Per  Second; 

Wan  de  r__An  g  1  e 

in 

Radiant; 

Eaet_Velocity 

out  Faat  Far  Sacond; 

North_Velocity 

out  Feet_Per  Second)  ; 

procedure  Compute  Earth  Relative  Horizontal  Velocitiea 

(Nominal_Eaet_Velocity 

in 

Matara  Par  Sacond; 

Nominal  North  Velocity 

in 

Matara  Far  Sacond; 

Wander  Angle 

in 

Radi  ana; 

Eaat_Velocity 

out  Metere__Per  Second; 

North  Velocity 

out  Matara_Par  Sacond) ; 

end  Overloaded  Method; 

Figure  48.  Overloaded  Method 


Other  overloaded  subprograms  would  allow  Wander_Angle  in  degrees  and  semicircles.  This  is 
the  method  used  by  Ada  packages  such  as  STANDARD.  CALENDAR,  and  TEXT_IO  to  provide  iden¬ 
tical  opeiations  on  different  data  types. 

The  overloaded  method  offers  the  protection  of  strong  data  typing  with  simplicity  of  design  and 
use  of  parts.  The  designer  will  decide  which  combinations  of  data  types  to  allow  for  each  part  and  will 
explicitly  declare  the  parameter  interfaces  nr  each  overloaded  subprogram.  He  will  also  define  all  of  the 
mathematical  parts  which  the  subprograms  will  use:  sine  and  cosine  for  Wander_Angle,  and  the  mul¬ 
tiplication  and  subtraction  operators.  Strict  type  checking  will  assure  that  actual  and  formal  parameters 
match  and  that  the  values  of  the  actual  parameters  fall  within  ranges  allowed  by  the  type. 

Because  Ada  supports  this  overloading  of  subprogram  definitions,  the  user  need  not  call  a 
version  of  a  part  specific  to  a  given  combination  of  data  types:  the  Ada  disambiguation  feature  will 
resolve  the  call.  In  fact,  should  user  requirements  change  and  a  different  combination  of  data  types  result, 
the  call  need  not  be  changed,  the  Ada  language  will  resolve  the  new  reference.  This  method  therefore 
provides  simplicity  of  use  with  the  protection  associated  with  strong  data  typing. 

The  major  disadvantage  of  this  method  is  the  large  number  of  parts  declared  at  the  architectural 
level.  For  the  data  types  stated  above  (Feet_Per_Second  and  Meters_Per_Second  for  velocities  and 
Radians,  Degrees,  and  Semicircles  for  angles),  the  Compute_Earth_Relative_Horizontal_Velocities  pro¬ 
cedure  would  require  six  specifications  and  bodies  to  accommodate  the  different  combinations  of  data 
types.  A  navigation  package  encapsulating  a  complete  set  of  reusable  navigation  parts  could  easily  grow 
to  over  100  subprograms.  Thus,  the  overloaded  method,  while  simple  to  use,  would  be  almost  impossible 
to  develop  and  maintain. 

c.  (ieneric  Mel  hod 

The  generic  method  uses  Ada  generic  units  to  provide  parts  which  are  tailorable  to  user-defined 
data  types.  Figure  49  shows  the  generic  method  applied  to  the  Compute_Earth_Relative_Horizontal_ 
Velocities  procedure  using  generic  formal  types  for  Velocities,  Angles,  and  Sin_Cos_Ratio  (the  type 
returned  by  a  call  to  Sine  or  Cosine),  and  generic  formal  subprograms  for  the  required  trigonometric 
functions  and  the  multiplication  operator.  The  subtraction  operator  operates  only  on  the  generic  velocity 
type  and  is  implicit  from  the  generic  definition. 

The  generic  formal  subprogram  parameters  are  used  within  the  body  of  (he  part  to  perform 
mathematical  operations  on  objects  of  the  generic  data  types.  For  example,  the  sine  and  cosine  operations 
on  Wander_Angle  are  performed  by  the  functions  supplied  as  actual  parameters  for  the  generic  Sin  and 
Cos.  The  user  must  define  operators  to  perfomi  these  functions  on  objects  of  the  actual  type  for  Angles 
returning  an  object  of  the  Sin_Cos_Ratio  type.  This  large  number  of  generic  parameters  could  place  an 
enormous  burden  on  the  part  user,  requiring  him  to  create  and  supply  all  of  the  needed  actual  parameters, 
both  types  and  subprograms.  For  the  example,  the  user  must  supply  three  data  types  plus  three  sub¬ 
programs  as  actual  parameters. 

A  method  which  uses  default  parameters  could  alleviate  some  of  this  overhead  from  the  part’s 
user.  If  (lie  total  parts  design  includes  typical  data  types  and  provides  functions  for  typical  combinations 
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g**  uric 

typ*  Sln_Co*_R*t  io  1*  digits  O; 

t yp«  Vwlocltl**  lu  digit*  <>; 

typu  Jtnglw*  1*  digit*  O: 

with  function  (Loft  :  Valocltlu*. 

Right  :  91n_Co*_R*t  lo>  ittum  Vwlocltl**  1*  <>; 
with  function  Sin  (In_Angl»  :  Anglos)  r*turn  31n_Co*_R»tlo  1*  <>; 

with  function  Co*  (In_Angl*  :  Angles)  r*turn  91n_Co*_R*tlo  1*  <>; 

procedure  Cowg>utw_**rth_R*l*tlww_ioriiontsl_Vwlocltle* 

(Howiln*l_***t_VwlocIty  :  In  Velocltl**; 

Hoi*lnwl_Ilorth_Veloclty  :  In  Velocities, 

Wend*r_Angle  In  Angle*; 

East  Vwloclty  out  Velocities; 

Rorth_V*loclty  out  Velocities) ; 


Figure  49.  Generic  Method 

of  these  data  types,  then  the  user  could  provide  predefined  types  as  actual  type  parameters  and  the  actual 
subprogram  parameters  will  default  to  the  predefined  functions.  Figure  50  illustrates  this  method.  Using 
the  same  example,  the  design  could  incorporate  a  separate  data  types  pai  supplying  a  Radians  type  and 
trigonometric  operations  on  Radians.  The  multiplication  operator  could  be  similarly  predefined.  This 
approach  yields  a  tunneling  of  parameters,  where  explicit  use  of  a  type  allows  tunneling  of  operators  on 
that  type.  The  advantage  of  this  method  is  clear  the  user  obtains  the  protection  associated  with  strong 
data  typing  and  the  flexibility  of  using  a  choice  of  data  types  without  the  need  to  define  his  own  types  or 
operators. 

WANCCR  VJMLTTW  HAOOATCN  PARTS 


Figure  50.  Tunneling  of  Parameters 
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d.  Abstract  State  Machine  Method 


The  abstract  state  machine  method  affords  the  part  user  a  very  high-level  interface  to  reusable 
parts,  hi  this  method,  the  interface  is  a  package  structure  defining  all  of  the  characteristics  of  the  missile 
slate  relevant  to  a  group  of  navigation  operations.  In  a  state  machine,  the  interface  is  strictly  through  the 
operations,  as  the  user  does  not  have  direct  access  to  or  knowledge  of  the  data  structure  on  which  the 
operations  work  (Reference  11,  pp  202).  The  stale  machine  allows  the  underlying  structure  to  change 
without  the  users’  knowledge. 

The  state  machine  implementation  of  a  navigation  system  would  provide  all  of  the  operations 
needed  to  perform  the  navigation  function,  both  those  changing  the  state  and  those  reporting,  the  state. 
One  such  function  would  be  the  Compute_Earth_Relative_Horizonal  .Velocities  operation  which  would 
both  update  and  report  the  velocity.  Figure  51  contains  a  code  segment  to  illustrate  the  abstract  state 
machine  method. 


generic 

type  3in_Co*_R*tio  it  digit*  <>; 

type  Velocities  1*  digit*  <>; 

typ*  Angle*  1*  digit*  <>; 

type  Altitude*  i*  range  <>; 

with  function  (Left  :  Velocities; 

Right  :  Sin__Co*_Ratio)  return  Velocities  is  <>; 
with  function  Sin  (Xn_Angle  :  Angles)  return  Sin_Cos_R*tio  is  <>; 

with  function  Co*  (In_Angle  :  Angle*)  return  Sin_Co*_Ratio  1*  <>; 

package  Navigation_State_Machine  is 

procedure  Coinpute_Earth_Relative_Hori*ontal_Velocitie* 

(Nominal_Ea*t__Velocities  :  in  Velocities; 

Nominal_North_Velocitie*  :  in  Velocities; 

Wander__Angle  :  in  Angles; 

Ea*t__Velocities  out  Velocities; 

North_Velocitles  out  Velocities); 

procedure  0pdate_Altitude 

(V*rtical__Velocitie*  :  in  Velocities; 

Current_Altitude  out  Altitudes); 

--  --operation*  to  provide  state  information 

function  Current_Ia*t_Velocitiea  return  Velocities; 

function  Current_North  Velocities  return  Velocities; 

end  Navigation_9tate_Machine; 


Figure  51.  State  Machine  Method 


The  abstract  state  machine  approach  utilizes  generic  units  to  tailor  operations  to  the  user's 
requirements.  Like  the  generic  method,  this  approach  enforces  strong  data  typing  and  protection  against 
misuse.  However,  because  all  operations  arc  encapsulated  in  a  single  package,  the  user  is  presented  wiUi 
an  "all  or  nothing"  solution:  specify  all  of  the  generic  parameters  for  all  operations,  whether  needed  or 
not,  or  don’t  use  the  package. 

An  alternative  approach  would  be  to  encapsulate  the  data  typing  and  structure  within  the  pack- 
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age,  forcing  the  pari  user  (o  convert  his  typing  to  conform  to  that  of  the  abstract  state  machine.  While 
defining  all  internal  data  type:  and  operations  makes  the  part  easier  to  use,  the  overhead  of  conversion  to 
the  internal  data  structure  would  be  prohibitive.  This  conversion  would  entail  not  only  data  typing,  but 
also  unit  conversion,  from  meters  to  feet,  radians  to  degrees,  etc.  The  package  could  provide  interfaces  to 
simplify  the  unit  conversion,  but  could  do  little  to  alleviate  the  overhead. 

The  state  machine  approach  does  offer  an  advantage  of  creating  more  than  one  body  for  a  single 
specification.  Because  all  data  is  controlled  within  the  body,  a  part  user  may  use  only  the  specification 
and  write  his  own  body,  defining  data  according  to  his  own  choice.  Similarly,  the  parts  designer  may 
provide  multiple  bodies  for  a  single  specification,  thus  alleviating  the  efficiency  issues  by  creating  bodies 
which  are  efficient  for  a  particular  situation.  Like  the  overloaded  method,  this  increases  the  cost  of  creat¬ 
ing  parts,  yet  is  an  effective  method  when  the  choice  of  a  data  structure  cannot,  for  reasons  of  efficiency 
or  simplicity,  be  established  in  the  package  specification. 

e.  Abstract  Data  Type  Method 

Like  the  abstract  state  machine  method,  the  abstract  data  type  method  offers  the  part  user  a 
high-level  interface  to  reusable  parts.  This  interface  consists  of  a  predefined  set  of  operations  on  a  data 
structure,  and.  unlike  the  abstract  state  machine,  the  interface  includes  the  data  structure  itself.  The  user, 
therefore,  knows  the  structure  he  is  dealing  with  and.  depending  on  the  implementation,  may  even  be  able 
to  access  the  structure  directly.  In  the  abstract  data  type  method  the  user  is  aware  of  changes  to  the  state 
of  the  structure  which  are  effected  by  the  exported  operations. 

In  most  implementations,  an  abstract  data  type  restricts  access  to  objects  of  the  abstract  type  to 
operations  defined  in  the  package  specification.  In  contrast  to  the  abstract  stale  machine,  this  type  is  part 
of  the  specification,  and  the  package  body  must  operate  on  (hat  unique  structure.  If  a  part  user  wishes  to 
use  the  operations  of  the  abstract  data  type  but  use  a  different  data  structure,  then  he  must  not  only  rewrite 
the  body  which  will  operate  on  the  data  structure,  but  also  rewrite  the  specification  which  defines  the 
structure.  This  method  is  used  extensively  in  abstract  data  structures  such  as  vectors  and  matrices,  stacks 
and  queues,  but  is  less  appropriate  for  more  complex  data  structures  such  as  those  used  by  a  navigation 
system  or  Kalman  filler. 

A  package  which  implements  the  navigation  system  according  to  the  abstract  data  type  method 
looks  quite  similar  to  that  of  the  abstract  state  machine.  (See  Figure  52.)  The  major  distinction  is  the 
private  section  of  the  specification  which  defines  the  abstract  data  structure. 
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g«n«ric 

typ*  Sin_Co«_Ratio  i*  digits  <>; 

typ*  Vttlocititta  is  digits  <>; 

typs  Anglos  is  digits  <>: 

typo  Altitudoo  is  rang*  <>; 

with  function  (Lsft  :  Velocities; 

Right  :  Sin_Coo_Ratio)  return  Velocities  is  <>; 
with  function  Sin  (In_Anglo  :  Angles)  return  Sin_Co*_Ratio  is  <>; 

with  function  Cos  (In_Anglo  :  Angles)  return  3in_Cos_Ratio  is  <>; 

pookogo  Novigot ion_St oto__Mochino  is 

type  Novigot  lon__Modol  is  private; 

procedure  Update_Earth__Relative_Borizontal_Velocitles 

(Nomlnol_Ro»t_Volocity  :  in  Velocities; 

Nominol_North_Volocity  :  in  Velocities); 

procedure  Cornpute__Earth_Relatlve_Horisontal_Velocitles 
(Updating  :  in  out  Navigation_Model) ; 

procedure  Update_Vertical__Velocity) 

(Vertical^Velocity  :  in  Velocities); 

procedure  Compute_Altitude 

(Updating  :  in  out  Navigatlon_Model)  ; 

--  --operations  to  information  from  data  structure 

function  Current_East__Velocity 

(Boood_On  :  Novigot ion_Modol)  return  Velocities; 

function  Current_North_Velocity 

(Based_On  :  Novigot ion_Modol)  return  Velocities; 

private  --  Definition  of  Navigation  Abstract  Data  Structure 

type  Navi  gat  ion__Modol  is 
record 

Missile__Velocity  :  Velocities; 

Missile_Altitude  :  Altitudes; 

end  record 

end  Novigot  lon_Stoto_Mochlno; 


Figure  52.  Abstract  Data  Type  Method 

This  method  is  similar  to  the  abstract  state  machine  approach  in  that  it  utilizes  generic  units  to 
tailor  operations  to  the  user’s  requirements.  It  uses  these  generic  units  to  enforce  strong  data  typing  and 
protect  against  misuse.  However,  the  user  is  again  presented  with  an  "all  or  nothing"  solution.  Again,  the 
abstract  data  type  offers  an  alternative  approach  which  would  define  data  types  in  the  package  specifica¬ 
tion,  eliminating  all  of  the  generic  units.  While  defining  all  internal  data  types  and  operations  will  ease 
the  use  of  the  part,  the  overhead  of  conversion  to  the  internal  data  structure  would  be  prohibitive. 


f.  Skeletal  ('ode  Method 


The  skeletal  cade  method  provides  the  part  user  with  code  templates,  which  may  be  manipu¬ 
lated  in  an  editor  or  through  some  other  tool.  This  approach  gives  the  part  user  the  flexibility  of  generic 
units,  without  (he  complexity  of  the  generic  instantiation.  A  sample  template,  as  shown  in  Figure  33  for 
(he  Compute_Eartli_Relative_Horizontal_Velocities.  would  look  similar  to  the  code  for  the  typeless 
method. 


procadura  Compute  Earth_Ralat iva_Hori rontal  Valocitiai 

(Nominal  Eaat  Velocity 

in  _ ; 

Norainal__North  Velocity 

in  _ ; 

Wandar_Angla 

in  _ ; 

Eaat  Velocity 

out  ; 

North_Valooity 

out  _ ) ; 

Figure  53.  Skeletal  Code  Template  Method 


This  approach  would  add  complexity  by  requiring  the  part  user  to  complete  much  of  the  en¬ 
vironment.  Outside  (he  part,  he  must  edit  the  skeletal  code  into  his  existing  design,  inserting  data  types 
and  overloaded  operators  as  required.  While  the  generic  method  provides  a  generic  specification,  and 
forces  conformity  through  the  Ada  generic  matching  rules,  the  skeletal  method  can  only  provide  user 
documentation  to  support  creation  of  the  environment.  In  addition,  if  two  or  more  designers  are  using 
similar  parts,  they  may  choose  different  values  for  completing  the  templates,  duplicating  parts  of  the 
environment.  There  would  also  be  a  tendency  to  avoid  strong  data  typing  to  alleviate  the  overhead 
attached  to  creation  of  overloaded  operators  and  functions. 

An  expert  system,  interfacing  to  the  code  templates,  could  support  use  of  the  skeletal  code 
method.  The  expert  system  could  prompt  the  user  for  information  it  needs  to  fill  in  the  blanks,  but  rules, 
stored  in  the  expert  system  knowledge  base,  would  allow  the  system  to  complete  the  environment,  filling 
in  additional  types,  operators,  and  any  additional  subprograms.  The  expert  system  approach  offers  the 
long-temi  solution  to  the  difficulties  of  the  skeletal  method  by  building  the  environment  as  a  by-product 
of  the  user  dialogue. 

3.  US  1C  OF  THE  (iICNERIC  METHOD 

The  CAMP  program  conducted  a  thorough  analysis  of  each  method  for  design  of  reusable  parts. 
Figure  54  summarizes  (he  results  of  this  analysis  and  compares  advantages  and  disadvantages  of  methods. 
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METHODS 


ADVANTAGES 


DISADVANTAGES 


TYPELESS  APPROACH 


No  need  to  define  new  No  protection  against 
operators  misuse 

Simple  interface 


OVERLOADED  APPROACH 


GENERIC  APPROACH 


-> 

x  :  A; 

r\ 

-> 

<- 

y  :  B; 
z  :  C; 

0 

GWBtfc  PARAMETERS 


All  operators  provided 
Flexible 

Protected  against 
misuse 


Too  many  parts 
Maintenance  night¬ 
mare 


Flexible  for  new  data 
types 

Protected  against 
misuse 


User  must  provide 
all  operators 
Complex  interface 
(generics) 


ABSTRACT  DATA  TYPE  & 
ABSTRACT  STATE  MACHINE  APPROACHES 


Protected  against  "All  or  nothing  at 

misuse  all”  approach 

Inefficient 
Complex  interface 
(instantiate  entire 
package  even  if 
only  one  subpro¬ 
gram  needed) 


SKELETAL  APPROACH 


Flexible  User  must  create 

data  environment 
User  must  build  in 
own  protection 
Requires  automated 
assistance  for 
productive  use 


Figure  54.  Comparison  of  the  Six  Reusable  Parts  Methods 
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The  analysis  focused  on  die  generic  method  as  providing  the  greatest  potential  for  the  design  of 
reusable  parts.  Prior  Data  Sciences,  a  Canadian  firm  specializing  in  the  development  of  reusable,  real¬ 
time  software,  has  summarized  the  difficulties  in  developing  reusable  software  based  on  generic  units  and 
of  employing  parts  created  using  generic  units. 

•  "Library  generic  units  arc  very  difficult  to  write  .  .  .  the  effort  required  to  properly  generalize  them 
is  usually  significant." 

•  "Generic  units  are  also  difficult  to  use.  especially  when  they  have  many  interrelated  parameters. 
The  parameter  matching  rules  can  be  very  subtle."  (Reference  12,  p  70) 

Although  generic  units  add  complexity  to  the  interfacing  mechanism,  the  flexibility  and  protection 
against  misuse  which  they  afford  weigh  heavily  in  their  favor.  Generic  units  also  provide  flexibility  for 
tailoring  to  the  requirements  of  a  specific  application. 

The  CAMP  parts  development  team  conducted  an  analysis  to  determine  the  best  methods  for  support 
of  complex  operators  inside  the  body  of  parts  and  for  simplification  of  the  use  of  parts  developed  using 
the  generic  method.  The  CAMP  project  has  been  unique  in  its  investigation  of  these  areas.  Most 
reusability  studies  have  focused  primarily  on  abstract  data  types,  which  require  only  simple  generic 
operators,  e.g.,  integer  incrementation,  data  structure  iterators,  etc.  While  some  reusability  efforts  have 
addressed  the  needs  of  the  scientific  and  engineering  communities  for  mathematical  software,  the  result¬ 
ing  parts  support  neither  strong  data  typing  nor  user  selection  of  mathematical  operators  called  internal  to 
the  part.  The  following  two  subsections  address  two  key  issues  of  the  CAMP  project: 

•  The  approach  developed  on  CAMP  for  the  design  of  reusable  parts  using  the  generic  method:  and, 

•  The  use  of  those  parts  in  constructing  an  application  from  reusable  software 

a.  Using  the  (Jeneric  Method  to  Design  Parts 

Effective  use  of  generic  units  for  the  creation  of  reusable  parts  requires  reconciliation  between 
the  complexity  of  the  generic  specification  and  the  desired  ease  of  use  of  the  part.  The  presentation  of  the 
generic  method  discussed  the  conflict.  In  fact,  the  conflict  entails  the  same  trade-offs  as  those  required  to 
create  reusable  software:  generality  vs.  efficiency  and  ease  of  use. 

The  CAMP  parts  fully  exploit  the  Ada  generic  facility.  Low-level  parts  are  designed  as  generic 
packages  or  subprograms.  Higher-level  parts  are  built  from  multiple  levels  of  these  generic  units.  The 
user  supplies  actual  parameters  to  instantiate  the  generic  parts  and  tailor  them  to  his  application.  The 
CAMP  part  architecture,  with  multiple  layers  of  generic  units  provides  the  part  user  with  a  broad  choice 
in  his  selection  of  parts  for  an  application:  he  may  use  low-level  parts  to  implement  low-level  features  of 
the  individual  objects  of  his  design  or  choose  high-level  parts  to  themselves  serve  as  objects  in  his  design. 

A  generic  part  uses  its  generic  formal  parameters  for  tailoring  the  part  to  a  specific  application. 
The  Compute.  Earth  Rclative_Horizon(al  Velocities  part  may  be  tailored  for  velocity  type  (feet  per 
second,  meters  per  second,  miles  per  hour,  knots)  and  for  angle  type  (radians,  degrees,  semicircles).  In 
addition,  the  tailoring  can  extend  to  the  return  type  of  a  sine  or  cosine  operator. 


In  order  lo  complete  the  tailoring,  the  part  must  also  allow  tailoring  for  operators  essential  for 
the  enforcement  of  strong  data  typing.  Generally,  operators  are  merely  overloadings  of  predefined  opera¬ 
tions  ("+", For  more  complex  operations,  the  user  must  create  his  own  subprograms,  such  as 
sine  and  cosine,  filters,  matrix  operations,  etc.  For  these  user-created  operations,  there  are  no  language- 
defined  constructs  and  the  generic  specification  cannot  fully  describe  the  required  operation.  Only  part 
documentation  and  the  user's  familiarity  with  the  part's  internal  design  can  support  creation  of  actual 
parameters  to  match  the  formal  generic.  Those  features  of  a  part  which  are  truly  common  between 
applications,  and  are  captured  in  the  body  of  the  part,  include: 

•  the  use  of  generic  data  types 

•  the  sequence  of  operations 

•  data  types  and  operations  not  parameterized  through  the  generic 

Figure  55  shows  the  use  of  generic  plus  non-generic  features  of  a  part  body.  The  formal  data 
types  and  Sin  and  Cos  operations  are  generic  and,  hence,  tailorable.  The  multiplication  operator  is  also 
generic.  The  subtraction  and  addition  operations  are  not  generic.  Of  course,  the  sequence  of  operations 
to  calculate  the  output  velocities  is  also  non-generic. 

procadura  Cotnput a_Earth_Ralatlva_Horizontal_yalocltlaa 

(Nomlnal_Eaat_Valocity  :  In  Valoaitlaa; 

Nomlnal_Morth_Valoalty  :  In  Valoaitlaa; 

Wandar_Angla  :  In  Anglaa; 

Eaat_Valocity  out  Valoaltlaa; 

Horth_Valoclty  out  Valoaitlaa)  la 

91n_W_A  :  Sln_Coa_R*tlo; 

Coa_N_A  :  Sln_Coa_Ratlo; 

bagin 

3 1  n_H_A  :m  sin  (Currant_1fandac_Angla) ; 

Coa_W_A  :«■  Coa  (Currant_Handar_Angla)  ; 

Eaat_Valocity  : «  Nomlnal_Eaat_Valoclty  *  Coa_W_A  - 

Homlnal_Horth_Valoclty  *  Sln_W_A; 

North_Valoclty  :■  Nomlnal_North_Valoclty  *  Coa_W_A  + 

Nomlnal_Eaat_Valoalty  *  Sin_W_A; 

and  Cong>uta_Earth_Ralatlva_Horliontal_Valocitlaa; 

Figure  55.  Commonality  Captured  in  the  Generic  Part  Body 
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b.  Using  Parts  to  Construct  an  Application 


The  difficulty  of  the  generic  method  stems  from  the  large  number  of  data  types  required  by  a 
part  and  the  resulting  large  number  of  operators  on  objects  of  those  types.  In  the  example  introduced 
above,  the  thiec  data  types  lead  to  only  three  required  operators.  In  addition,  part  use  is  further  simplified 
by  the  defaulting  mechanism  of  Ada  generic  units.  Because  the  three  operators  exist  for  a  limited  range 
of  data  types,  the  CAMP  parts  structure  can  provide  default  versions  for  each  operator.  Now  when  the 
user  supplies  actual  types  for  his  instantiation,  the  operators  can  default  through  the  tunneling  mechanism 
depicted  in  Figure  50.  The  user  may,  however,  wish  to  override  the  system’s  tunneling  of  parameters  by 
supplying  his  own  operators.  CAMP  parts  also  support  overriding  defaults  by  providing  a  selection  of 
such  common  operators  as  trigonometric  functions.  Figure  56  depicts  the  mechanism  of  overriding 
defaults.  Here,  the  user  chooses  his  own  cosine  function  from  the  CAMP  Polynomials  package  to  over¬ 
ride  the  default  from  Standardjl  rig.  The  user  could  also  write  his  own  cosine  function  to  override  the 
default.  The  Ada  mechanism  to  accomplish  the  default  overriding  is  explained  in  Section  II. 


Where  the  mix  of  data  types  and  operators  grows  beyond  a  manageable  level,  the  need  to 
provide  additional  assistance  to  the  part  user  also  grows  The  generic  formal  part  of  the  CAMP 
Latcral/Dircctional  Autopilot  (Figure  57),  for  example,  includes: 

•  twelve  formal  data  types 

•  ten  formal  data  objects 
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generic 

--  --types  for  Ailerrm  b'np 

type  Roll  C'ommands  Is  digits  <>; 
type  Roll_Atlilude.i  Is  digits  <>: 

type  Roll_Comma»d_Gflins  Is  digits  <>: 


—types  for  Rtuhier  Loop 

type  Rudder.Cmd.RolI.Rate.Gains  b  digits  <>: 

type  Missile.Accelerations  Is  digits  <>: 

type  Acceleration.Gains  Is  digits  <>; 

type  Oravitational.Accelerations  Is  digits  <>; 

type  Velocities  Is  digits  «»>: 

type  Trig_Value  fa  digits  o: 


with  function  Acceleration.Filter 

(Lateral.  Ac  tele  rat  ion:  Missile^ Accelerations) 
return  Missile. Accelerations  b  <>; 

with  function  Sin  (Angle:  Roll. Attitudes) 
return  Trig.Value  b  <>; 

—  —Aileron  control  hop  gain  and  updater  functions 

with  function  (Left  :  Roll.Commands; 

Right  :  Roll. Attitudes) 
return  Roll.Commands  b  <>; 

with  function  (Left  :  Roll.Commands: 

Right  :  RolI.Command.Oains) 
return  Fin.Deflections  b  <>; 


—  —types  for  both  loops 

type  Feedback.Rate.Gains  b  digits  <>: 

type  Fin.Deflections  b  digits  <>: 

type  Feedback.Rates  b  digits  <>; 

—  —Initial  values  for  aileron  control  hop 

Initial_Aileron.Integrator.Oain 
In  RolI.Command.Oains: 

Initial.Aileron.Integrator.Limil 
In  Fin.Deflections: 

Initial_Roll.Command_Proportional.Oam  : 

In  RolI.Command.Oains: 

Initial.RolI.Rate.Oain.For.Ailcron 
In  Feedback.Rate.Gains: 

Initial.Y  awRatc.Oatn.For.Aileron 
In  Feedback.Rate.Oains; 

—  -Initial  values  for  rodder  control  loop 

Imtial.Rudder.Integrntor.Oain 
In  Acceleration.Oains: 

Initial.Rudder.Inlegrotor.Limit 
In  Fin.Deflections: 

Initial.Y  aw.Rate.Gain.For.Rudder 
In  Feedback.Rate.Oains: 

Initial.RolI.Rate.Gain.For.Rudder 
In  Rudder.Cnid.RolI.Ratc.Oains: 

Initial.Acceleration.Proportional.Oain 
In  Acceleration.Gains: 

--  -  A  Heron  contt  ol  hop  limiters  ami  filter 

with  function  Roll.Hrror.Limit 

(Roll.Command :  Roll.Commands) 
return  Roll.Commands  b  <>: 

with  function  Aileron.C  ommand.Limil 
(Fin.De  flee  lion  :  Fin.Deflections) 
return  Fin.Deflections  b  <>: 

with  function  Roll.Command.Filtcr 
(Roll.Command  •  Roll.Commands) 
return  Roll.Comn  wds  b  <>; 

—  —Rudder  control  loop  limiters,  filtcis.  and  tag  fundi  on 

with  function  Rudder.Command.Limit 
(Fin.De  flee  lion  :  Fin.Deflections) 
return  Fin.Deflections  b  <>: 

with  function  Yaw.Rale.Fille  r 
(Yaw.Ratc:  Feedback. Rates) 
return  Fcedback.Rates  b  <>: 


with  function  (Left  :  Fcedback.Rates: 

Right  :  Feedback.Rate.Oains) 
return  Fin.Deflections  b  <>; 

--  -Rudder  control  loop  gain  and  updater  furu  tions 

with  function  (Left  :  Missile. Accelerations: 

Right  :  Acceleration.Oains) 
return  Fin.Deflections  b  <>; 

with  function  (Left  :  Fcedback.Rates; 

Right  :  Rudder.Cmd  .RolI.Rale.Gains) 
return  Fcedback.Rates  b  <>; 

with  function  (Left  :  Oravitational.Accelerations; 

Right  :Trig_Valuc) 
return  Gravitational. Accelerations  b  <>: 

with  function  7”  (Left  :  Gravitalional.Atrelerations; 
Right  :  Velocities) 
return  Feedback.Rates  b  <>: 

package  Lateral.Directional.Autopilot  b 

type  Aileron.Rudder.Commands  b  record 
Aileron  .Command :  Fin.Deflections: 

Rudder.Command  :  Fin.Deflections: 
end  record: 


procedure  Initialize.Lateral.Directional .Autopilot 


(Initial.Ailcron.Command 
In  it  i  al.R  uddcr.Com  m  a  od 
Oravitational.Acceleration 
Roll.Command 
Roll.Attilude 
RolI.Rate 
Y  aw.Ratc 
Missile.VcIiKity 
Lateral  Acceleration 


In  Fin.Deflections; 

In  Fin.Deflections: 

:  In  Oravttational.Accelerations; 
:  In  Roll.Commands; 

:  In  Roll.At  til  odes; 

:  In  Feedback.Rates; 

:  In  Feedback.Rates; 

:  In  Velocities; 

:  In  Missile. Accelerations); 


function  Compute.Aileron.Rudder.Commands 


(Roll.Command 
Roll.Attilude 
RolI.Rate 
Yaw.Rate 

Lateral.  Acceleration 
Missile.Velocity 
Gravitational. Acceleration  : 


In  Roll.Commands; 

In  Roll.Attitudea; 

In  Feedback.Rates; 

In  Feedback.Rates; 

In  Missile.Accelerations; 

In  Velocities: 

In  Gravitational. Accelerations) 


return  Aileron.Rudder.Commands; 


end  Lateral.Directional.Autopilot; 


Figure  57.  Autopilot  Part  Generic  Specification 


96 


•  seven  language-independent  operations 

•  seven  language-defined  operations 

The  CAMP  design  structure  eases  the  burden  of  the  part  user  by  supplying  packages  of  standard 
data  types  which  may  serve  as  actual  types  for  the  generic  forma!  types,  packages  of  standard  operators  to 
supply  actual  subprograms  for  the  generic  formal  subprogram  operations,  and  a  mix  of  operators  over¬ 
loading  the  language-defined  operations.  The  user’s  task  is  now  reduced  to  selecting  the  proper  combina¬ 
tion  of  data  types  and  operators  from  the  parts  base.  He  may  create  his  own,  if  the  CAMP  parts  base  is 
deficient  in  some  area,  but  an  attempt  has  been  made  to  cover  a  high  degree  of  variability.  Furthermore, 
the  parts  base  is  easily  extended  to  allow  for  new  standard  types  and  operators.  Figure  58  shows  the 
range  of  selections  open  to  the  CAMP  parts  user. 
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4.  SEMI-ABSTRACT  DATA  TYPE 


The  combination  of  high-level  parts  with  lower  level  support  packages  providing  actual  types  and 
operators  leads  to  the  creation  of  a  complete  environment  for  use  of  a  part.  The  CAMP  program  has 
established  that  it  is  essential  to  provide  support  for  a  complete  environment  to  incorporate  reusable 
software  into  a  design.  Others  have  noted  the  importance  of  the  environment  because  "(t]he  very  concept 
of  reusability  must  be  defined  ...  in  terms  of  the  cependence  of  the  component  on  enclosing  or  higher 
level  environments”  (Reference  13,  p  550).  The  CAM  method  uses  the  term  part  bundle  to  describe  the 
environment  that  consists  of  a  combination  of  packages  required  to  support  a  part  plus  the  context  clause 
the  user  must  specify  to  obtain  the  environment. 

The  part  bundle  allows  the  user  access  to  a  predefined  packaging  structure.  Availability  of  this 
structure  eases  part  use  by  providing  the  user  the  environment  he  needs  to  use  a  part.  Figure  59  shows  the 
complete  bundle  required  to  support  the  Autopilot  package  part.  In  order  to  use  this  package,  the  user 
must  first  import  the  Autopilot  part  itself.  In  addition,  he  needs  data  types  supplied  by  the  Basic_  and 
Autopilot_Data_Types  parts,  and  signal  processing  and  trigonometric  operations  supplied  by  the  Signal_ 
Processing  and  Polynomial  parts,  respectively.  The  user  is  unaware  of  bundles  which  exist  to  support  the 
lower  level  packages;  for  example,  SignaLProcessing  bundles  General_Purpose_Math,  and  Basic_Data_ 
Types  bundles  Standard_Trig,  Conversion_Factors,  and  Universal_Conslanls. 


Figure  59.  Autopilot  Bundle  Structure 


While  the  bundle  gives  the  user  an  environment  for  use  of  a  part,  the  user  must  still  extract  entities 
provided  by  the  bundle  for  tailoring  the  part  to  his  application.  In  addition,  the  user  may  modify  the 
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bundle,  overriding  aspects  of  die  bundle  by  supplying  other  CAMP  parts  from  CAMP  packages  or  his 
own  parts.  This  open  architecture  —  the  ability  of  the  user  to  supply  his  own  data  types  and  operators  — 
is  one  of  the  key  design  features  of  CAMP  parts  use. 

The  term  semi-abstract  data  type  is  used  to  formally  describe  this  open  architecture  of  the  CAMP 
generic  method.  As  opposed  to  the  abstract  data  type  which  defines  an  abstract  data  structure  and  opera¬ 
tions  on  that  structure  for  its  use,  the  semi-abstract  data  type  is  very  much  under  user  control. 

The  use  of  the  Autopilot  bundle  illustrates  the  capabilities  of  the  semi-abstract  data  type.  Were  the 
Autopilot  part  defined  as  an  abstract  data  type,  all  data  structures  and  operations  would  be  encapsulated 
and  hidden  within  (he  part,  with  the  user  tailoring  the  part  through  the  generic  formal  parameters.  As 
previously  described  under  the  abstract  data  type  method,  the  user  could  not  gain  access  to  any  of  the 
part’s  facilities,  data  structures  or  operations,  without  going  through  the  part.  In  contrast,  the  semi¬ 
abstract  data  type  allows  the  user  access  to  a  bundle,  which  also  provides  access  to  all  the  part’s  facilities. 
In  addition,  the  bundle  allows  access,  on  an  individual  basis,  to  data  types  from  the  types  packages  and  to 
functional  parts  from  the  Signal_Processing  or  Polynomial  packages.  The  user  is  free  to  use  these  lower 
level  parts  independently  of  the  Autopilot  part,  or  even  use  them  to  build  his  own  autopilot,  keeping  the 
bundle  but  not  using  any  of  the  CAMP  Autopilot  parts.  Alternatively,  he  may  use  only  a  subset  of  the 
part’s  facilities,  supplying  other  required  facilities  with  his  own  packages.  These  methods  of  use  address 
the  reuse  techniques  identified  by  Standish  (Reference  14.  p  496): 

•  Direct  reuse  of  concrete  modules  (=  high  level  reuse] 

•  Reuse  after  refinement  (=  lower  level  reuse] 

•  Reuse  after  modification  |=  independent  reuse] 

Actual  use  of  CAMP  parts  has  proven  the  effectiveness  of  the  semi-abstract  method.  Most  of  the 
parts  are  themselves  constructed  from  other  parts;  this  is  illustrated  by  the  background  bundling  of 
Signal_Processing  or  Basic_Data_Types  in  the  Autopilot  bundle.  Also,  applications  using  CAMP  parts 
have,  in  some  cases,  found  that  the  higher  level  part  is  not  complete  for  some  special  operations.  In  these 
situations,  the  CAMP  users  access  the  bundle,  taking  as  much  from  the  high  level  part  as  possible  and 
building  the  rest  from  lower  level  entities  in  the  bundle.  The  CAMP  Kalman  filter  bundle,  for  example, 
contains  a  GeneraI_Vector_Matrix_Algebra  part  (see  Figure  60.)  This  part  is  used  extensively  in  the 
instantiation  of  CAMP  Kalman  filter  parts.  A  user  of  the  CAMP  parts,  needing  additional  functions  not 
built  into  them,  can  build  the  required  functions  out  of  the  General_Vector_Matrix_Algebra  parts  or 
develop  his  own  operators  to  perform  the  same  functions.  Such  was  the  case  in  the  1 1th  Missile  Applica¬ 
tion,  where  special-purpose  matrix  operations  were  required  to  meet  performance  constraints  (see  Volume 
II,  Section  III).  By  building  these  special  operations  will)  interfaces  conforming  to  the  CAMP  GeneraL 
Vector_ Matrix  Algebra  parts,  the  I  Ith  Missile  development  team  was  able  to  use  the  high-level  Kalman 
filter  parts  without  modification. 
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Figure  60.  Knlman  Filter  Bundle  Structure 


5.  SUMMARY 

Use  of  CAMP  parts  in  additional  applications  will  demonstrate  the  complete  potential  of  the  CAMP 
method.  Applying  this  method  to  parts  in  other  domains  will  also  show  the  power  of  the  CAMP  approach 
to  an  integrated  parts  base.  The  ease  with  which  parts  can  be  fit  into  an  application  has  already  shown  the 
method  to  be  extremely  effective  and  a  significant  boost  to  productivity  (see  Volume  II).  Parts  have  been 
easy  to  maintain,  and  the  CAMP  parts  base  has  been  extended  as  applications  discover  the  need  for 
additional  parts.  The  CAMP  team  has  applied  the  reusable  parts  method  for  the  development  of  parts  to 
meet  current  needs  and  will  continue  to  apply  this  method  as  the  parts  base  matures. 
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SECTION  VII 


ADA  COMPILER  VALIDATION  AND  SOFTWARE  REUSABILITY 

1.  INTRODUCTION 

An  important  part  of  the  CAMP  project  was  the  development  of  a  part  design  methodology  by  which 
Ada  parts  can  simultaneously  be  reusable,  transportable,  flexible,  efficient,  easy  to  use,  and  protected 
against  misuse.  These  seemingly  conflicting  design  goals  are  achieved  by  exploiting  many  of  the  ad¬ 
vanced  features  of  Ada,  such  as  derived  types  and  subprograms,  generic  units  with  default  formal 
parameters,  and  subprogram  overloading.  Section  VI  discussed  these  features  as  they  apply  to  design  of 
the  CAMP  parts.  This  section  discusses  the  impact  of  these  features  on  parts  implementation  and  com¬ 
piler  selection. 

2.  DISCUSSION 

To  achieve  these  design  goals,  the  CAMP  design  method  included  the  use  of  generic  units,  strong 
data  typing,  and  generic  object  and  subprogram  parameter  defaults. 

•  Generic  units:  The  primary  facility  Ada  provides  which  promotes  reusability  is  the  generic  unit. 
Although  some  people  in  the  Ada  community  have  expressed  a  "fear"  of  this  feature,  MDAC-STL 
has  embraced  it  wholeheartedly.  Without  generic  units,  reusability  in  Ada  would  not  be  achievable 
at  a  meaningful  level.  However,  there  is  a  risk  associated  with  using  generic  units  —  Ada  com¬ 
pilers  must  be  able  to  implement  them  efficiently  and  correctly. 

•  Strong  data  typing:  Among  the  most  important  capabilities  in  Ada  is  the  ability  to  strongly  type 
data.  However,  strong  data  typing  has  two  characteristics  which  unnecessarily  cause  many  people 
(including  some  part  developers)  to  avoid  it: 

-  The  use  of  strong  data  typing  makes  the  design  of  generic  packages  and  subprograms  more 
complex. 

-  The  interaction  of  Ada  typing  rules  with  other  Ada  features  such  as  generic  units  is  non¬ 
trivial  to  master. 

For  these  reasons,  some  software  developers  have  developed  Ada  parts  in  a  typeless  fashion.  We 
believe  (his  is  a  mistake.  Parts  which  are  typeless  are  very  prone  to  misuse.  It  is  only  reasonable 
that  if  the  parts  being  developed  are  intended  for  long-term  use,  then  it  should  be  worth  the  effort  to 
build  them  in  the  most  protected  fashion. 

•  Generic  object  and  subprogram  parameter  dclaults:  As  previously  mentioned,  the  use  of  strong 
data  typing  causes  generic  units  to  be  more  complex.  Specifically,  the  generic  packages  and  sub¬ 
programs  must  now  import  many  operations  and  functions  which  would  otherwise  be  visible  to 
them  implicitly  through  the  scoping  rules  of  Ada.  If  this  drawback  could  not  be  overcome,  it  would 
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be  a  good  argument  against  strong  data  typing.  However,  Ada  provides  a  feature  —  the  specifica¬ 
tion  of  defaults  for  generic  object  and  subprogram  parameters  —  which  negates  the  drawback  while 
still  retaining  the  advantages.  This  feature,  the  generic  unit,  and  its  use  for  part  design  is  further 
discussed  in  Section  VI .3. a. 

a.  A  Sample  System 

The  complexity  of  reusable  generic  parts  can  range  from  extreme  simplicity  (see  Figure  61)  to 
considerable  complexity  (see  Figures  62  and  63),  with  most  falling  somewhere  in  between  (see  Figure 
64). 


with  CALENDAR; 
gtntde 

package  Clock_Handlar  la 

function  Currant_Tlae  raturn  STANDARD. DURATION; 

function  Convartad_Tlau»  (Clock_Tljne  :  In  CALENDAR. TXMI) 
return  STANDARD. DURATION ; 

procedure  Reset_Clock; 

procedure  Synehronlie_Clock 

(NewJTlae  :  In  STANDARD .  DURATION; 

Clock _Tlaie  :  In  CALENDAR . TIME  :>  CALENDAR. CLOCK)  ; 

function  Elapaed_TlM  return  STANDARD . DURATION; 
end  Clock_Handler; 

Figure  61.  Generic  Units  Can  Be  Very  Simple 

While  most  generic  units  have  minimal  complexity  in  and  of  themselves,  their  use  in  the 
development  of  a  system  can  become  quite  involved.  This  is  because  even  though  an  individual  generic 
unit  may  be  relatively  independent  of  othei  generic  units,  it  has  probably  been  designed  to  be  used  in 
conjunction  with  other  generic  units. 

Figure  65  illustrates  the  parts  that  may  be  required  in  the  design  of  a  smill  portion  of  a  naviga¬ 
tion  system.  In  order  to  instantiate  three  north-pointing  navigation  parts  (Coriolis_Acceleration, 
Radius_of_Curvature.  and  Latilude_Integration)  using  strong  data  typing  where  all  floating  point  types 
are  separate  Ada  data  types,  the  following  must  occur: 

l.Ten  packages  must  be  compiled  into  the  user’s  library.  The  user  himself  requires  six  of  these 
(indicated  by  the  arrows  going  into  the  user  application).  These  six  require  an  additional  four. 
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ganarlc 

typw  L*ft_Indlc*a  la 
typa  Rlght_Indicw«  la 
typa  Raault_Indlaaa  la 
typa  Laft_Elananta  la 
typa  Rlght_Ilamanta  la 
typa  Raault_Clamanta  la 
typa  Laft  Vactora  la 
typa  Rlght_Vactora  la 
typa  Raault_Vaotora  la 
XI  :  In  Laft_Indlcaa 

T1  :  In  Laft_Indicaa 

Z1  :  In  Laft_Indicaa 

X2  :  In  Rlght_Indleaa 

Y2  :  In  Rlght_Indloaa 

Z2  :  In  Right_lndlcaa 

X3  :  In  Raault_Indloaa 

Y3  In  Raault_Indlcaa 

Z3  :  In  Raault_Indlaaa 

with  function  "  +  "  (Laft 

Right 

with  function  (Laft 

Right 

with  function  (Right 

with  function  (Laft 

Right 


«»; 

«» ; 

«»; 

privata; 

privata; 

privata; 

privata; 

privata; 

privata; 

Laf t_Indicaa '  FIRST; 

:w  Laf  t_Indlcaa '  SOCC  (Laf  t_Indioaa '  FIRST)  ; 

Laf t_Indloaa ' LAST; 

Right_Indicaa  ’  FIRST; 

Rlght_Zndlcaa '  SOCC  (Right_Indicaa '  FIRST)  ; 
Right_Indioaa' LAST; 

Raault_Indlcaa '  FIRST; 

:»  Raau lt  lndlcaa '  SOCC  (Raault_Indlcaa' FIRST)  ; 

:m  Raault_Indicaa ' LAST; 

:  Raault_Elamanta ; 

:  Raaul t_Elamanta )  raturn  Raault_ElaaMnta  la  <>; 
;  Raault_Elananta; 

;  Raault_Elamnta)  raturn  Raault_Elaaanta  la  <>; 
:  Raault_Elaaianta )  raturn  Raault_ElaaMnta  la  <>; 
:  Laf  t_Elaawnta; 

;  Rlght_Elaatanta)  raturn  Raault_Ela«aant a  la  <>; 


with  function  Ratrlavad_Elamant 

(Vactor  ;  Laft_Vacto.ra; 

Indax  ;  Laft_Indlcaa )  raturn  LaftJElaaMnta  la  <>; 
with  function  Ratriavad_Elaawnt 

(Vaator  :  Rlght_Vactora; 

Indax  :  Rlght_Indlcaa )  raturn  Rlght_Elaaianta  la  <>; 
with  procadura  Sat_Elamant 

(Indax  ;  in  Raault_Indloaa; 

Valua  :  In  Raault_EIamanta; 

Vactor  :  out  Raault_Vactora)  la  <>; 

function  Ganarlc_Croaa_Product  (Laft  ;  Laft_Vaotora; 

Right  :  Rlght_Vaotora ) 
raturn  Raault  Vactora; 


Figure  62.  Some  Generic  Unils  Can  Be  Very  Complex 

2.  The  user  must  do  the  following  before  instantiating  the  navigation  parts: 

•  Instantiate  four  versions  of  the  square  root  package  (GPMath.Square_Root)  using  data  types 
and  operators  supplied  by  the  basic  data  types  (BDT)  package. 

•  Instantiate  four  versions  of  the  vector  operations  package  (CVMA.Vector_Opns)  using  data 
types  and  operators  supplied  by  BDT  and  the  square  root  functions  contained  in  the 
packages  previously  instantiated  by  the  user. 

•  Instantiate  a  cross  product  function  using  scalar  data  types  and  operations  supplied  by  BDT, 
along  with  vector  data  types  and  operations  obtained  from  three  separate  instantiations  of 
CVMA.Vector_Opns. 

3.  The  three  navigation  parts  can  then  be  instantiated  using: 

•  Scalar  data  types  and  operators  supplied  by  BDT. 
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paclugt  Dlr*otlon_Co*ln*_Matrlx_Op«ration«  la 
gonarlc 

typa  Earth_Ax*«  la  (<>)  ; 

typa  Navigatlon_Axaa  la  (<>) ; 

typa  9in_Coa_Ratio  la  digit*  <>; 

typa  Raal  la  dlglta  <>; 

with  function  Sqrt  (Valua  :  Sln_Co«_Rati 
with  function  (Laft  :  31n_Co*_Rati 

Right  :  Sln_Coa_Ratl 
with  function  (Laft  :  •ln_Coa_Ratlo 

Right  :  Raal)  rat urn 

Graanw  :  In  Earth_Axa*  :  «  Earth_Axa«  '  n 
Right  :  In  Earth_Axaa  Earth_Axa*  '  St) 
Polar  :  In  Earth_Axaa  : “  Earth_Axaa  'LA 
Eaat  :  In  Navlgatlon_Axa*  : -  Navlgatlo 
North  :  In  Navigation_Axa*  : ■  Navlgatlo 
Op  :  In  Navigation_Axa*  :«  Navlgatlo 


packaga  CNE_Oparationa  la 


:  Sln_Coa_Ratlo)  raturn  Sln_Coa_Ratlo  la  <>; 

:  31n_Coa_Ratlo; 

:  Sln_Coa_Ratlo)  raturn  Raal  la  <>; 

•ln_Coa_Ratlo; 

Raal)  raturn  91n_Coa_Ratio  la  <>; 

Earth_Axaa  'FIRST; 

Earth_Axaa  '  SOCC (Earth_Axaa' FIRST) ; 

Earth_Axaa  '  LAST; 

ia  : m  Navlgation_Axaa  'FIRST; 

ia  : ”  Navlgatlon_Axaa  '  SOCC(Navlgatlon_Axaa'FIRST)  ; 
ia  :«  Navlgatlon_Axaa  '  LAST; 


typa  CNE_Matrlcaa  la  array  (Earth_Axaa,  Navi gat lon_Axaa)  of  Bln  Coa  Ratio; 


funatlon  CNE_Inltlallcad_From_Rafaranca  (Raf_CNE_2_l 

Ra  f  ~CNE_2_2 
Raf_CNE_3_l 
Raf_CNE_3_2 
Sign_of_2_3 
Sign_of_3_3 


Sln_Coa_Ratlo; 

S ln_Coa_Rat lo ; 

Sln_Coa_Ratlo; 

Sln_Coa_Ratlo; 

INTEGER? 

INTEGER) 


raturn  CNE  Matrlcaa; 


ganarlc 

typa  Earth_Poaltlona  la  dlglta  <>; 
typa  Anglaa  la  dlglta  <>; 

with  procadura  31n_Coa  (Input  :  In 

Sln_Valua  :  out 

Coa_Valua  :  out 

with  procadura  31n_Coa  (Input  :  in 

Sln_Valua  ;  out 

Coa  Valua  :  out 

function  CNE  Initlallxad  from  Earth  Rafaranca 


In  Anglaa ; 

out  Sln_Coa_Ratlo; 
out  SIn_Coa_Ratlo)  la  <>; 
in  Earth_Poaltiona; 

out  Sln_Coa_Ratlo; 
out  Sin  Coa  Ratio)  la  <>; 


(Nandar_Angla 

Latltuda 

Longltuda 


Anglaa; 

Earth_Poaltlona; 

Earth  Poaltlona)  raturn  CNE  Matrloaa; 


and  CNE  Oparatlona; 


and  01ractlon_Coalna_Matrlx_0paratlona; 


Figure  63.  Nested  Generic  Units  Can  Be  Very  Complex 

•  Scalar  data  types  and  trigonometric  functions  supplied  by  an  instantiation  of  the  standard 
trig  package  contained  in  BDT  (BDT.Trig). 

•  Vector  types  and  operations  supplied  by  the  four  instantiations  of  CVMA.Veclor_Opns. 


Data  constants  supplied  by  the  WGS72  ellipsoid  metric  data  package  (WGS72)  and  the 
WGS72  ellipsoid  unitless  data  package  (WGS72U). 


•  User-defined  data  types  and  objects. 


ganaric 

typ«  Unit_Vactora  la  privata; 

typa  9in__Coa__Ratio  la  digit a  <>; 

with  funotion  "/*'  (Laft  :  Unit__Vactora ; 

Right  :  Sin_Coa_R*tio)  rttum  Unifc_Vactora  la  <>; 
with  funotion  Croaa_Product  (Laft  :  Unlt_Vactora; 

Right  :  Unit_Vactora) 
rat urn  Unit_Vactora  ia  <>; 
with  function  Vactor_Langth  (Input  :  Unit_Vactora) 

ratum  3in_Coa_Ratio  ia  <>; 

function  Unit__Nonaal__Vactor 

(Unit_Radial_A  :  Unit_Vactora; 

Unit  Radial  B  :  Unit  Vactora)  ratum  Unit  Vactora; 


Figure  64.  Most  Generic  Units  Have  Minimal  Complexity 


wmw 

UnlvConet 


(^)  AO 


pkg  VeISqRt  Is  new  GPMath.Square_Poot . 
pkg  AngVeISqRt  Is  new  GPMath.Square_Root 
pkg  AcceISqRt  Is  new  GPMath.Square_Root ... 
pkg  DIstSqRt  Is  new  GpMath.SquareRoot ... 

pkg  VelVOpns  Is  new  CVMA.Vecfof_Opns  ... 

pkg  AngVelVopns  Is  new  CVMA.Vector_Opns ... 
pkg  AecelVOpns  Is  new  CVMA.Veetor_Opns  ... 

pkg  DlstVOpns  Is  new  CVMA.Vector_Opns  ... 

In  CrossProd  AW  W  Is  new  CVMA  Cross  Product . 


In  CorAecel  Is  new  NPNav. Compute_Cork>ll$_Acceleratlon 
pkg  RadOICurv  Is  new  NPNav.  RadiusofCurvature  ... 
pkg  Latlnt  Is  new  NPNav. Latltudejntegratlon  ... 


Figure  65.  Assembling  a  North-Pointing  Navigation  System 
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b.  CAMP  Experience  With  Ada  Compilers 

The  development  and  use  of  truly  good,  flexible,  reusable  software  will  succeed  only  if  generic 
units  are  fully  supported  by  Ada  compilers.  Yet,  during  the  CAMP  project,  we  observed  that  validated 
Ada  compilers  frequently  cannot  handle  any  hut  the  simplest  generic  units. 

During  the  CAMP  project,  there  were  many  opportunities  to  see  how  compilers  handled  generic 
units.  Three  compilers  were  used  on  the  CAMP  project  (two  validated  and  one  prevalidated,  of  which 
two  were  1750A-targeted),  and  versions  of  the  CAMP  parts  were  submitted  to  three  additional  validated 
compilers.  Of  these  six  Ada  compilers,  only  one  validated  compiler  was  able  to  handle  the  parts  sub¬ 
mitted  to  it,  and  even  that  one  was  able  to  do  so  only  after  a  year  and  a  half  of  the  CAMP  team  working 
with  the  vendor. 

While  various  problems  were  encountered,  they  all  had  one  thing  in  common  —  they  involved 
the  use  of  generic  units.  Some  of  these  problems  are  enumerated  below. 

•  Difficulties  in  handling  a  multitude  of  instantiations.  Using  the  code  represented  in  Figure  65  as  an 
example,  one  compiler  was  able  to  compile  all  of  the  CAMP  parts  required  to  develop  the  user 
application.  However,  when  an  attempt  was  made  to  compile  the  user  code,  the  compiler  crashed. 
(It  should  be  noted  that  the  user  code  was  legal  Ada  and  did  compile  on  another  validated 
compiler.) 

•  Difficulties  in  declaring  derived  real  types  when  the  base  type  was  a  generic  formal  type,  par¬ 
ticularly  if  a  range  constraint  was  added  (see  Figure  66).  Attempting  to  do  this  sent  one  compiler 
into  an  infinite  loop.  Another  compiler  allowed  the  derived  type  to  be  declared,  but  encountered  an 
internal  error  when  an  attempt  was  made  to  restrict  the  range  of  the  newly  declared  derived  type. 

•  Incorrect  passing  of  the  value  of  a  generic  actual  object  to  a  generic  actual  subprogram  —  the 
compiler  sent  a  value  of  0.0  regardless  of  the  actual  value  of  the  object.  The  generic  actual  object 
was  a  named  number  defined  in  a  package  which  had  to  be  imported  by  the  user  application.  This 
error  occurred  only  when  strong  data  typing  was  employed  (i.e.,  a  different  generic  actual  type  was 
specified  for  each  of  the  generic  formal  data  types),  not  occurring  when  FLOAT  was  used  for  all 
actual  types.  Additionally,  even  when  strong  data  typing  was  employed,  this  error  did  not  occur  if 
an  explicit  type  conversion  was  performed  on  the  object  at  the  time  it  was  used  in  the  instantiation 
and  also  did  not  occur  if  a  literal  was  used  instead  of  the  named  number. 

•  Inability  to  resolve  overloading  of  operators  when  a  generic  formal  subprogram  ("+"  in  this  case) 
matched  an  operator  already  defined  by  the  language  (see  Figure  67). 

•  Inability  to  identify  generic  actual  subprograms  to  be  used  as  defaults  even  though  they  were 
directly  visible.  Two  variations  of  this  problem  occurred  and  are  illustrated  in  Figure  68.  In  the 
first,  the  correct  subprogram  was  directly  visible  as  the  result  of  ’with’  and  ’use’  clauses  on  the 
subprogram’s  package.  In  the  second  case,  the  correct  subprogram  was  directly  visible  since  it  was 
a  generic  actual  subprogram  to  the  part  where  problems  were  encountered. 


•  An  inability  to  handle  separate  compilation  of  generic  units,  even  though  compiler  documentation 
indicated  this  optional  feature  was  implemented. 


This  code  sent  one  compiler  into  an  infinite  loop: 

generic 

type  Angle*  1*  digit*  <>; 
type  Ratio*  1*  digit*  <>; 

Pi  :  in  Angle*; 
package  StdTrig  1* 

type  Radian*  1*  new  Angle*;  * 

end  StdTrig; 

*  This  statement  caused  the  problem 


This  code  caused  another  compiler  to  encounter  an  internal  error: 

generic 

type  Angle*  1*  digit*  <>; 
type  Ratio*  1*  digit*  <>; 

Pi  :  in  Angle* ; 
package  StdTrig  1* 

type  Radian*  i*  new  Angle*; 

type  Sin__Co*_Ratio  1*  new  Ratio*  range  -1.0..  1.0;  ff 
end  StdTrig; 

#  -  This  statement  caused  the  problem 


Figure  66.  Some  Compilers  Couldn’t  Handle  Type  Derivations 
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Specification : 

generic 

type  M_Indicee  la  (<>) ; 

type  N_Indicea  la  (<>) ; 

type  P_Xndic*a  la  (<>) ; 

type  Left_Elaoeni:a  la  digit  a  <>; 

type  Rlght_Elementa  la  dlgita  <>; 

type  Reault_Elenenta  la  dlgita  <>; 

type  Left_Matrioea  la  array  (M_Indloea,  N_Indloea)  of  Left_Blaotenta; 

typa  Rlght_Matrloea  la  array  (N_Xndioaa,  P_Indloae)  of  Right_El«Mnta; 

type  Reeult_Matrioea  la  array  (M_Xndiaea,  P_Indloea)  of  Reeult_Elaa»nte; 

with  function  (Left  :  Laft_Elaatanta; 

Right  :  Rlght_Elaaente)  return  Reault_Elaaanta  la  <>; 
with  function  "4-"  (Left  :  Raault_ElaaMnta ; 

Right  :  Reeult_Elaaienta)  return  Reault_Elamente  la  <>; 
function  Hatrix_Matrlx_Multlply 

(Left  :  Left_Matrlcaa; 

Right  :  Right_Matrlcee)  return  Reault_Matricaa ; 

Body : 

function  Matrix_Matrix_Multiply 
(Left  :  Lef t_Matrlcee ; 

Right  :  Right_Matricee )  return  Raault_Matrlcaa  la 
Anawer  :  Reault_Matricea; 
begin 

for  M  in  M_Xndicea  loop 
for  P  in  P_Xndicea  loop 
Anawer (M,  P)  0.0; 
for  II  in  N_Xndlcea  loop 

Anawer (M, P)  :«  Anawer (M, P)  4  # 

Left (M, H)  *  Right (H,  P); 

end  loop; 
end  loop; 
end  loop; 
return  Anawer; 

end  Matrlx_Matrlx_Multlply; 


#  -  Compiler  wan  unable  to  resolve  this  overloading 


NOTE-  Contained  arrays  were  used  in  the  design  of  this  part  in  order  to  improve  the  efficiency  of  the  part.  While  it  was 

recognized  that  unconstrained  arrays  would  have  made  the  part  more  flexible  and  hence  more  reusable,  the  need  for 
efficiency  for  real-time  embedded  applications  was  considered  of  greater  importance. 

Figure  67.  Overloaded  Operator  Caused  Problems  for  Compiler 
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When  attempting  to  instantiate  the  following  generic: 

gutrio 

typa  Anglaa  la  dlglta  <>; 

typa  Input a  la  dlglta  <>; 

typa  Outputa  la  dlglta  <>; 

typa  Sln_Coa_Ratlo  la  dlglta  <>; 

with  function  Sin  (Input  :  Anglaa)  raturn  31n_Coa_Ratlo  la  <>; 
function  Exanpla  (Input  :  Inputa)  raturn  Outputa; 

One  compiler  couldn't  resolve  the  default  even  though  the  appropriate  subprogram  was  directly 
visible  through  'with'  and  'use'  clauses: 

ganarlc 

typa  Anglaa  la  dlglta  <>; 
typa  Ratloa  la  dlglta  <>; 
packaga  Stdlrlg  la 

typa  Radiana  la  naw  Anglaa; 

typa  Sin_Coa_Ratio  la  naw  Ratloa  ranga  -1.0.  .1.0; 
funotlon  Sin  (Input  :  Radi an a )  raturn  Sin_Coa_Ratlo; 
and  StdTrlg; 

with  StdTrlg; 
packaga  BDT  la 

typa  Raal  la  dlglta  9; 

packaga  Trig  la  naw  StdTrlg  (Anglaa  ■>  Raal, 

Ratloa  ■>  Raal); 

and  BDT; 

with  BDT;  uaa  BDT; 
with  Exanpla; 

procadura  Oaar_Applicatlon  la 
uaa  BDT.Trlg; 

funotlon  Attanptad_Inatantlatlon  la  naw  Exaag>la 
(Anglaa  «>  BDT. Trig. Radlana, 

Inputa  — >  BDT. Raal, 

Outputa  ■»>  BDT.  Raal, 

Sln_Coa_Ratio  — >  BDT.  Trig.  Sln_Coa_Ratlo)  ; 

bagln 

and  Oaar_Applloation; 

Another  compiler  couldn  t  resolve  the  default  e'  en  though  it  was  visible  as  a  generic  formal 
subprogram: 

gsnsrlc 

typs  Anglaa  is  digits  <>; 

typs  Inputs  is  digits  <>; 

typs  Outputs  is  digits  <>; 

typs  Sin_Cos_Rstio  is  digits  <>; 

with  function  Sin  (Input  :  Anglos)  rsturn  Sin__Cos__Rstio  is  <>; 
pseksgs  Samp Is  is 

snd  9snpls; 

with  Exampls; 
packaga  body  Saumpls  is 

function  Attsmptsd_In*t*nti*tlon  is  naw  Exsjnpls 
(Anglos  — >  Angles, 

Inputs  ■>  Inputs, 

Outputs  ■>  Outputs, 

Sin_Cos_R*tio  ■>  Sin_Cos_Ratio)  ; 

•nd  Sample; 


Figure  68.  Compilers  Had  Problems  Finding  Default  Subprograms 
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c.  Compiler  Validation 

The  Ada  Compiler  Validation  Capability  (ACVC)  test  suite  is  designed  to  ensure  a  certain  level 
of  quality  and  confidence  in  Ada  compilers,  and  to  a  large  extent  has  succeeded.  The  CAMP  experience, 
however,  indicates  that  notable  inadequacies  exist  in  the  area  of  generic  units.  These  inadequacies  could 
have  a  significant  negative  impact  on  the  future  development  and  use  of  reusable  software. 

The  use  of  generic  units  is  vital  to  the  development  of  good  reusable  parts,  yet  we  have  found 
that  it  is  one  area  where  even  validated  compilers  often  are  lacking.  Based  on  the  CAMP  experience, 
most  validated  Ada  compilers  seem  to  be  able  to  handle  simple  generic  units,  many  are  unable  to  handle 
complex  generic  constructs,  and  most  are  unable  to  handle  the  complex  mix  of  generic  units  that  is 
required  to  assemble  a  software  system  from  a  collection  of  reusable  generic  parts. 

The  tests  in  It  "’VC  test  suite  seem  to  be  geared  to  lest  or  demonstrate  only  a  single  objec¬ 
tive.  While  this  has  ensured  that  validated  compilers  can  generally  handle  simple  generic  units,  it  is 
probably  why  an  Ada  compiler  can  be  validated  though  unable  to  handle  complex  generic  units,  and  is 
certainly  why  a  complex  mix  of  generic  units  is  beyond  the  ability  of  most  validated  Ada  compilers. 
While  this  approach  may  have  been  appropriate  in  the  beginning  when  there  was  a  derire  to  get  an  initial 
set  of  validated  compilers,  we  feel  the  time  has  come  to  modify  this  approach. 
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SECTION  VIII 


CONCLUSIONS  AND  RECOMMENDATIONS 

Given  the  palhfinding  nature  of  CAMP-2,  it  is  not  surprising  that  many  lessons  were  learned  con¬ 
cerning  the  use  of  Ada  to  develop  reusable  software  for  real-time,  embedded  (RTE)  applications.  One  of 
the  primary  benefits  of  the  CAMP-2  project  has  been  in  sharing  these  "lessons  learned"  with  the  DoD 
software  engineering  community.  This  section  discusses  the  major  conclusions  reached  during  the 
CAMP-2  project  and  presents  recommendations  based  on  these  conclusions. 

I.  ON  THE  APPROPRIATENESS  OF  ADA  FOR  REUSABLE  SOFTWARE 

A  primary  design  goal  of  the  Ada  programming  language  was  to  promote  reuse  of  software.  The 
designers  of  Ada  addressed  this  goat  in  two  ways.  First,  Ada  was  designed  to  facilitate  transporting 
applications  between  different  computer  architectures.  Second,  Ada  was  designed  to  facilitate  the 
development  of  code  units  which  could  be  transported  between  different  applications. 

Conclusion  #1 

With  a  few  minor  exceptions.  Ada  achieves  its  reusability  design  goal. 

Conclusion  #1  is  substantiated  by  two  facts.  First,  many  Ada  applications  have  been  transported 
between  different  computer  architectures  at  a  small  fraction  of  the  cost  traditionally  associated  with 
rehosting  non-Ada  applications.  Second,  Ada  parts  are  rapidly  becoming  available  from  a  variety  of 
sources  (including  CAMP)  and  these  parts  are  being  reused.  The  CAMP  parts  have  been  distributed  to 
over  120  DoD  agencies  and  contractors  who  are  exploring  their  utility  in  a  wide  spectrum  of  applications 
(e.g.,  avionics,  ballistic  missiles,  space  station  control,  etc.).  McDonnell  Douglas  is  in  the  process  of 
using  the  CAMP  parts  on  a  number  of  applications. 

There  are  several  primary  factors  which  have  led  to  Ada’s  success  in  the  area  of  reusability. 

•  The  DoD  has  rigidly  adhered  to  a  standard  language  definition 

•  Ada’s  package  feature  provides  the  user  with  the  means  to  encapsulate  machine  and  application 

dependencies 

•  Ada’s  generic  unit  feature  provides  the  ability  to  broaden  the  domain  applicability  of  reusable 

components 

•  Ada  allows  the  underlying  machine  architecture  to  be  hidden 

However,  there  are  some  aspects  of  Ada  which  need  to  be  improved  from  the  perspective  of 
reusability.  Section  V  describes  the  rationale  for  these  recommendations  in  more  detail. 

Recommendation  #1 

The  definition  of  Ada  should  be  changed  to  allow  address  objects  to  be 
passed  as  generic  parameters. 


Ill 


Recommendation  #1  will  promote  reuse  of  machine  control  and  communication  software.  For  ex¬ 
ample,  during  the  CAMP-2  lllh  Missile  Demonstration,  a  Bus  Interface  Module  component  was 
developed  which  could  be  reused  between  the  Guidance  computer  TLCSC  and  the  Navigation  computer 
TLCSC.  The  only  difference  was  the  actual  physical  address  of  the  bus  discretes.  Since  address  objects 
cannot  be  generic  parameters,  manual  changes  had  to  be  made  to  the  component  in  order  reuse  it. 

Recommendation  #2 

The  definition  of  Ada  should  he  changed  to  allow  representation  clauses 
to  he  defined  within  a  package  body. 

Recommendation  #2  will  uncouple  the  physical  and  logical  definitions  of  Ada  entities  and  hence 
promote  reuse.  The  current  requirement  to  define  a  representation  clause  within  the  same  declarative 
scope  as  the  entity  declaration,  means  that  if  a  different  application  wants  to  reuse  a  component  with  the 
same  logical  representation  but  a  different  physical  representation,  it  must  manually  change  the  com¬ 
ponent. 


Recommendation  #3 

The  definition  of  Ada  should  he  changed  to  allow  a  single,  unmodified 
Ada  specification  to  he  used  with  multiple  bodies  within  a  single 
application. 


Recommendation  #3  will  increase  the  degree  to  which  Ada  specifications  can  be  reused  without 
manual  modifications.  For  example,  currently,  to  use  two  different  bodies  to  implement  a  single  abstract 
data  structure  within  an  application,  the  specification  must  be  copied  and  manual  name  changes  must  be 
made  to  it. 


Recommendation  #4 

The  definition  of  Ada  should  he  changed  to  require  a  compiler  to  support 
separate  compilation  of  generic  units  and  subunits. 

Recommendation  #4  will  decrease  compilation  overhead  when  software  components  are  leused. 
This  change  will  have  a  significant  beneficial  impact  on  reuse  since  there  are  real  advantages  to  separate 
compilation  in  the  areas  of  configuration  management,  project  management,  and  compilation  time. 

Recommendation  #5 

The  definition  of  Ada  should  he  changed  to  allow  procedural  data  types. 


Recommendation  #5  will  promote  reuse  within  applications  that  require  dynamic  reconfiguration 
and  within  Artificial  Intelligence  applications. 
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2.  ON  THE  APPROPRIATENESS  OF  ADA  FOR  REAL-TIME  EMBEDDED  REUSABLE 
SOFTWARE 

Another  Ada  design  goal  was  that  it  he  suitable  for  use  in  RTE  applications.  This  implies  that  Ada 
must  not  only  provide  efficient  higher-order  language  (HOL)  features,  but  must  also  allow  the  program¬ 
mer,  when  needed,  to  have  direct  control  over  the  representation  of  Ada  entities,  access  the  computer 
hardware  directly,  trade-off  space  and  execution  time,  closely  control  and  be  able  to  characterize  the 
dynamic  behavior  of  a  program,  and  in  general,  to  perform  operations  which  a  non-RTE  programmer 
might  consider  "unsafe". 

The  appropriateness  of  Ada  for  RTE  applications  depends  on  four  factors.  These  factors  are  dis¬ 
cussed  in  the  following  subsections. 

•  Is  Ada  an  effective  language  for  RTE  applications? 

•  Arc  there  any  features  in  Ada  which  must  be  used  in  RTE  applications  but  are  inherently  in¬ 
efficient? 

•  Are  Ada  compilers  sufficiently  effective  for  RTE  applications? 

•  Is  the  code  produced  by  Ada  compilers  sufficiently  efficient  for  RTE  applications? 

Obviously,  when  one  addresses  either  of  the  last  two  issues,  it  must  be  done  based  on  experience 
with  a  particular  set  of  compilers  during  a  specific  period  of  time.  Thus,  the  conclusions  reached  on  the 
CAMP-2  project  concerning  Ada  compilers  are  dependent  upon  the  specific  compilers  used  and  the  time 
period  in  which  they  were  used. 

a.  On  the  Effectiveness  of  Ada 

A  determination  of  the  effectiveness  of  the  Ada  language  for  RTE  applications  is  essentially  a 
determination  as  to  whether  all  the  functional  requirements  or  RTE  applications  can  be  achieved  within 
(he  language.  In  other  words,  if  there  are  operations  that  an  RTE  application  typically  needs  to  perform, 
and  cannot  do  si)  using  the  language,  (hen  Ada  would  be  judged  ineffective  to  some  degree. 
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Conclusion  #2 

Ada  is  an  effective  language  for  real-time  embedded  applications. 

Conclusion  #2  is  based  on  the  CAMP-2  1 1th  Missile  Application  experience.  The  11  th  Missile 
Application  was  constructed  using  only  21  assembly  language  statements;  this  equates  to  0.1%  of  the 
total  software  (see  Volume  II  for  more  details).  With  the  exception  of  two  small  functions,  all  the 
functional  requirements  of  the  11th  Missile  Application  were  achieved  using  Ada.  In  fact,  the  21  as¬ 
sembly  language  statements  could  have  been  coded  using  Ada’s  machine  code  insertion  feature.  In  the 
case  of  the  1 1th  Missile  Application,  the  functions  which  required  the  use  of  assembly  language  had  to  do 
with  operating  system  idiosyncracies.  But,  every  RTE  system  lends  to  have  its  own  idiosyncracies.  The 
reassuring  fact  is  that  Ada  can  handle  all  these  situations,  assuming  that  machine  code  insertion  is  sup¬ 
ported.  In  existing  RTE  applications  that  use  HOLs,  the  percentage  of  assembly  language  used  for 
functional  reasons2  is  usually  much  higher  than  that  experienced  on  CAMP. 

A  common  myth  concerning  Ada,  which  needs  to  be  dispelled,  is  that  Ada  slops  a  programmer 
from  doing  certain  operations  which  are  considered  to  be  "unsafe"  but  which  RTE  programmers  need  to 
do.  If  this  myth  were  true,  it  would  indeed  be  a  major  problem  with  Ada.  The  reality  is  that  the  software 
engineering  discipline  has  recognized  that  certain  programming  paradigms  are  dangerous  (i.e.,  their  use 
frequently  leads  to  errors)  and  in  most  cases  these  paradigms  can  be  avoided.  In  some  languages,  like 
Pascal,  a  dogmatic  approach  has  been  adopted  and  these  paradigms  are  outlawed  completely.  This  is  not 
the  case  with  Ada.  Ada  tries  to  balance  (he  goal  of  promoting  sound  software  engineering  principles  and 
the  reality  that  upon  occasion  a  programmer  needs  to  do  something  that  is  dangerous.  Thus,  Ada  allows 
the  programmer  to  use  "dangerous"  paradigms,  but  doesn’t  make  their  use  too  easy  —  a  suitable  com¬ 
promise  in  the  authors’  opinions.  An  example  of  an  operation  which  is  often  considered  dangerous  but 
which  is  essential  in  an  RTE  application  is  overlaying  two  data  structures  on  the  same  data. 

Conclusion  #3 

A  full  implementation  of  the  Chapter  13  features  of  Ada  is  essential  in 
real-time,  embedded  applications. 

Conclusion  #3  highlights  the  fact  that  the  effectiveness  of  Ada  for  RTE  applications  is  highly 
dependent  upon  the  extensive  use  of  Ada  features  which  are  defined  in  the  Language  Reference  Manual 
as  optional.  These  features  are  popularly  called  the  "Chapter  13  features"  of  Ada.  Projects  must  be 
sensitive  to  the  fact  that  in  RTE  applications,  the  Chapter  13  features  of  Ada  should  not  be  considered 
optional. 


2ln  addition  to  using  assembly  language  for  functional  reasons.  RTE  applications  frequently  have  to  replace  HOL  code  with 
assembly  code  for  performance  reasons. 
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I).  On  I  he  Inherent  Efficiency  of  Ada 

There  has  been  a  great  deal  of  debate  within  the  DoD  software  engineering  community  concern¬ 
ing  the  efficiency  of  the  Ada  language.  Much  of  this  debate  has  concentrated  on  the  efficiency  of  Ada 
features,  such  as  tasking,  exception  handling,  and  generic  units,  which  are  not  in  our  traditional  RTE 
languages. 


Conclusion  #4 

There  appears  to  he  no  Ada  features  which  are  inherently  inefficient. 

While  it  is  true  that  the  efficiency  of  the  advanced  Ada  features  as  implemented  by  the  current 
generation  of  Ada  compilers  leaves  something  to  be  desired,  a  preliminary  analysis  indicates  that  there  is 
nothing  within  the  definition  of  the  Ada  language  which  requires  them  to  be  inefficiently  implemented. 
The  inefficiently  results  mainly  from  a  lack  of  global  optimization  in  most  of  the  current  Ada  compilers. 

Conclusion  #5 

There  arc  Ada  features  which  require  a  global  optimizer  to  be  suf¬ 
ficiently  efficient  for  severely  constrained  RTE  applications. 

For  example,  consider  Ada  generic  units.  When  a  generic  is  compiled,  the  compiler  is  unaware 
of  the  values  of  the  generic  parameters  and  must,  therefore,  generate  code  which  can  handle  any  situation. 
This  results  in  code  that  will  be  relatively  inefficient.  However,  if  a  compiler  had  a  sufficiently  powerful 
global  optimizer,  it  could  use  the  information  known  at  the  point(s)  of  instantiation  and  optimize  the  code 
for  the  generic  unit. 

In  every  situation  where  inefficiencies  were  encountered  on  CAMP,  we  were  able  to  determine 
that  a  sufficiently  powerful  optimizer  could  have  corrected  the  situation.  Unfortunately,  few,  if  any,  of 
the  current  generation  of  Ada  compilers  implement  optimizers  which  are  sufficiently  powerful  for 
severely  constrained  RTE  applications.  The  next  two  subsections  discuss  Ada  compiler  issues  in  more 
detail. 

c.  On  Ihe  Effectiveness  of  Ada  Compilers 

Given  that  the  Ada  language  is  effective  for  reusable  RTE  software,  a  determination  of  the 
effectiveness  of  Ada  compilers  for  the  same  type  of  software  is  based  on  two  factors.  First,  Ihe  compiler 
must  properly  handle  all  mandatory  Ada  features.  The  ability  to  properly  handle  Ada  generic  units  is  of 
special  importance  given  the  crucial  role  (hat  generic  u. jits  play  in  reusability.  Second,  ihe  compiler  must 
handle  all  Chapter  13  features  in  Ada.  As  previously  discussed,  in  RTE  applications  these  features  are 
essential. 


Conclusion  #6 

Ada  compilers  do  exist  which  are  effective  for  real-time  embedded 
application. 

Conclusion  #6  is  based  on  the  fact  that  the  CAMP  1 1th  Missile  Application,  a  true  RTE  system, 
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was  implemented  using  only  21  assembly  language  statements.  This  system  was  tested  in  a  hardware-in- 
the-loop  simulation  environment  on  a  1750A  processor.  The  particular  1750A  Ada  compiler  used  for  this 
demonstration  had  an  excellent  implementation  of  the  Chapter  13  features  of  Ada.  This  is  not  to  imply 
that  these  compilers  handle  all  Ada  language  constructs  efficiently.  For  example,  even  the  1750A  Ada 
compiler  used  for  the  11th  Missile  demonstration  had  difficulties  with  complex  generics  and  efficient 
throughput  for  tasking. 


Recommendation  #6 

The  DoD  needs  to  enhance  its  Ada  Validation  process. 

Too  many  validated  compilers  have  detectable  errors.  Recommendation  #6  is  based  on  the  fact 
that  many  DoD  project  managers  mistakenly  believe  that  if  the  DoD  says  a  compiler  is  validated,  then  it 
must  be  OK  to  use.  It  is  important  to  note  that  it  was  only  in  the  final  months  of  the  CAMP-2  project  that 
we  had  a  I750A  Ada  compiler  that  met  most  of  our  RTE  effectiveness  requirements  (the  exception  was  in 
the  area  of  generic  units).  We  spent  a  significant  amount  of  time  and  effort  testing  compilers,  reporting 
problems,  and  working  with  the  compiler  developers  to  correct  the  problems.  During  a  large  portion  of 
this  time  the  compilers  were  validated. 


Recommendation  #7 

During  the  next  few  years,  DoD  mission-critical  real-time  embedded  Ada 
projects  should  establish  a  contractual  relationship  with  their  compiler 
developer  to  reduce  risk. 

Until  Ada  compilers  are  fully  mature,  critical  RTE  Ada  projects  will  be  well  served  to  acquire 
the  highest  level  of  maintenance  support  from  their  compiler  developer  or  to  put  them  under  a  special 
contract.  If  problems  are  found  with  the  compiler,  it  is  unrealistic  to  expect  major  projects  to  wait  for  the 
next  scheduled  release  to  get  the  problems  fixed.  On  CAMP-2,  it  was  mutually  advantageous  for  McDon¬ 
nell  Douglas  and  the  selected  1750A  Ada  compiler  supplier  to  work  closely  together. 

Conclusion  #7 

Ada  compilers  do  exist  which  are  effective  for  applications  that  want  to 
use  reusable  software  components. 

Conclusion  #7  is  based  on  the  fact  that  there  exist  compilers  which  hanult  Ada  generic  units 
effectively.  The  CAMP  project  has  had  a  great  deal  of  success  with  the  DEC  VAX  Ada  compiler. 

Conclusion  #8 

CAMP  data  indicates  that  the  current  generation  of  Ada/1 7 50 A  com¬ 
pilers  do  not  support  generic  units  well  and  this  lack  of  support  will 
hinder  real-time  embedded  applications  that  want  to  use  reusable 
software  components. 


Conclusion  #8  is  a  disappointing  result  based  on  (he  present  immaturity  of  1750A  Ada  com¬ 
pilers.  Obviously,  we  can  only  extrapolate  the  situation  with  I750A  Ada  compilers  to  other  RTE  com¬ 
pilers.  The  basic  problem  is  that  many  validated  Ada  compilers,  especially  those  which  target  RTE 
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computers,  do  nol  handle  generic  units  correctly.  Most  validated  compilers  handle  simple  generic  units  in 
an  adequate  fashion,  but  a  great  majority  of  Ada  compilers  will  have  problems  with  non-trivial  generic 
units.  Section  VII  discusses  the  types  of  situations  which  cause  most  compilers  to  have  problems. 

With  the  particular  I750A  Ada  compiler  used  on  the  11th  Missile  Application  (which  we 
believe  is  one  of  the  best  of  its  type),  we  spent  a  significant  amount  of  time  and  effort  working  with  the 
compiler  developer  to  overcome  problems  associated  with  generic  units.  Even  after  all  this  effort,  the 
result  was  that  all  the  CAMP  generic  parts  compiled,  most  of  them  linked,  but  many  of  them  caused 
abnormal  program  execution  due  to  compiler  errors.  To  overcome  these  compiler  problems,  we  had  to 
manually  instantiate  approximately  42%  of  the  CAMP  parts  used  on  the  1 1th  Missile  Application. 

Recommendation  #8 

The  Ada  Validation  suite  must  be  changed  to  incorporate  tougher  tests 
on  generic  units. 

During  CAMP-2,  a  benchmark  was  developed  which  rigorously  tests  a  compiler’s  ability  to 
deal  with  non-trivial  Ada  generic  units  (see  Volume  111) .  A  test  based  on  this  benchmark  would  give  Ada 
compiler  developers  the  incentive  to  effectively  handle  generics  —  if  they  don’t,  they  would  lose  their 
validated  status. 

d.  On  the  Efficiency  of  Ada  Compilers 

While  the  efficiency  of  the  code  produced  by  Ada  compilers  is  important  to  all  types  of  applica¬ 
tions,  it  is  critical  for  RTE  applications.  The  performance  requirements  of  RTE  applications  are  typically 
non-negotiable.  The  RTE  software  engineer  cannot  trade-off  run-time  speed  for  a  more  maintainable 
software  system,  nor  can  she  arbitrarily  accept  a  larger  object  code  size  for  the  sake  of  reusability. 

Another  aspect  of  efficiency  which  is  important  to  RTE  applications  and  which  many  non-RTE 
software  engineers  often  fail  to  understand  is  that  of  micro-level  efficiency.  In  other  words,  in  addition  to 
being  concerned  with  macro-level  efficiency  issues  such  as  the  selection  of  appropriate  algorithms,  the 
RTE  software  engineer  is  often  concerned  with  the  efficiency  of  specific  language  constructs.  The  au¬ 
thors  have  had  frequent  conversations  with  other  researchers  in  the  area  of  reusability  in  which  the  other 
researchers  could  not  understand  why  (he  CAMP  parts  were  designed  as  semi-abstract  parts  as  opposed  to 
being  developed  as  pure  abstract  data  structures.  In  their  value  system,  the  benefits  of  pure  abstract  parts 
more  than  accounted  for  a  "few  more  assembly  language  statements."  However,  in  many  RTE  applica¬ 
tions,  such  as  missile  guidance  and  navigation  systems,  a  few  more  statements  in  a  high  rate  (e.g.,  100 
hertz)  task  can  make  the  difference  between  an  effective  weapon  system  and  one  that  doesn’t  achieve  its 
operational  requirements. 


Conclusion  #9 

CAMP  data  indicates  that  current  implementations  of  Ada  tasking  arc 
sufficiently  inefficient  to  cause  concern  in  severely  constrained  RTE 
applications. 

The  speed  of  an  Ada  task  rendezvous  on  most  compilers  is  such  that  a  RTE  programmer  should 
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avoid  its  use  for  any  fast  loops  or  high  rale  interrupts.  Some  RTE  Ada  compiler  developers  have  recog¬ 
nized  this  problem  and  provided  an  alternative  method  of  handling  interrupts. 

Conclusion  #10 

CAMP  data  indicates  that  current  implementations  of  Ada  generics  are 
sufficiently  inefficient  to  cause  concern  in  severely  constrained  RTE 
applications. 

Currently,  there  are  two  approaches  used  by  Ada  compiler  developers  to  implement  generics: 
the  single  body  approach  and  the  multiple  body  approach.  With  the  single  body  approach,  a  single  unit  of 
code  is  generated  that  can  handle  any  type  of  instantiation;  this  approach  trades  speed  for  a  smaller  code 
size.  With  the  multiple  body  approach,  a  separate  set  of  code  is  generated  for  each  instantiation;  this 
approach  trades  code  size  for  better  speed.  In  general,  we  believe  that  the  multiple-body  approach  is 
better.  Our  preference  is  based  on  the  observation  that  most  parts  are  instantiated  only  once  within  an 
application.  Thus,  using  the  multiple  body  approach  provides  both  a  speed  and  storage  advantage. 
However,  both  approaches  suffer  from  the  inability  of  most  compilers  to  perform  global  optimization. 

Recommendation  #9 

Ada  compilers  should  he  able  to  alternate  between  single  body  and  mul¬ 
tiple  body  generic  implementation  based  on  either  implicit  or  explicit 
information. 

In  the  best  case,  the  compiler  should  be  able  to  use  both  the  single  body  and  the  multiple  body 
implementation  of  generic  units.  Ideally,  the  compiler  would  make  the  choice  of  the  implementation 
mechanism  based  on  data  provided  by  pragmas  and/or  a  global  optimization  analysis. 

Conclusion  #1 1 

CAMP  data  indicates  that  current  implementations  of  Ada  exceptions  arc 
sufficiently  inefficient  to  cause  concern  in  severely  constrained  RTE 
applications. 

Because  of  the  semantics  of  Ada  exceptions,  some  Ada  compilers  generate  code  which  waste  a 
significant  amount  of  storage.  In  effect,  they  keep  extra  copies  of  data  until  it  can  be  verified  whether  or 
not  an  exception  has  been  raised.  In  many  cases  this  extra  storage  is  not  significant,  but  in  some  cases 
where  the  data  being  duplicated  is  extensive,  e.g.,  an  Kalman  filter  arrays,  this  method  can  cause  severe 
memory  problems. 


Conclusion  #12 

With  the  e  xception  of  the  inefficiencies  due  to  generic  units,  tasking,  and 
exception  handling,  current  Ada  compilers  appear  to  have  efficiency 
equivalent  to  other  HOL  compilers  used  in  RTE  applications. 

When  one  ignores  the  advanced  features  of  Ada.  computational-intensive  benchmarks  show  that 
Ada  compilers  perform  as  well  as  JOVIAL  compilers. 
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Conclusion  #13 

The  ability  of  Ada  compilers  to  perform  global  optimizations  is  critical  to 
the  successful  use  of  Ada  and  the  reuse  of  Ada  parts  in  RTE  applications. 

If  there  is  one  major  message  concerning  compiler  efficiency  that  was  quite  clear  on  CAMP,  it 
is  that  Ada  compilers  need  a  global  optimizer  to  be  sufficiently  efficient  for  RTE  applications,  with  or 
without  reuse.  This  need  is  driven  by  several  factors. 

•  Ada’s  features  promote  design  of  highly  modularized  software,  thus,  Ada  software  is  usually  im¬ 
plemented  by  means  of  a  high  number  of  small  units.  If  an  Ada  compiler  cannot  optimize  across 
unit  boundaries,  a  large  amount  of  potential  optimization  will  be  lost. 

•  Reusable  parts  and  data  are  typically  bundled  together  into  cohesive  packages  to  make  their  use  and 
maintenance  easier.  If  a  compiler  cannot  perform  global  analysis  to  identify  and  eliminate  dead 
code  and  dead  data ,  some  of  the  benefits  of  reusable  parts  will  be  lost  when  the  user  has  to 
manually  eliminate  these  items. 

•  The  Ada  generic  unit  is  an  extremely  powerful  concept,  but  to  make  use  of  it  on  RTE  applications, 
the  compiler  must  be  able  to  optimize  the  code  generated  based  on  the  context  of  the  instantiation. 

•  Like  generic  units,  Ada's  exception  handling  features  are  very  useful,  but  compilers  must  not  penal¬ 
ize  the  user  who  has  decided  not  to  use  the  features. 

Given  that  few,  if  any,  Ada  compilers  currently  implement  a  sufficiently  powerful  global  op¬ 
timizer  for  RTE  applications,  an  important  question  is  whether  an  application  can  avoid  inefficiencies  by 
avoiding  certain  Ada  features.  The  answer  is  not  always.  Certainly  an  application  can  avoid  generics  and 
hence  avoid  the  overhead  of  a  generic.  However,  this  is  not  the  case  with  exceptions.  Whether  or  not  an 
application  uses  exceptions,  it  will  pay  the  costs  associated  with  detecting  and  communicating  exceptions 
because  without  a  global  optimizer,  the  compiler  cannot  know  that  an  exception  handler  is  not  declared  at 
a  higher  level. 

3.  ON  THE  DEVELOPMENT  OF  THE  CAMP  PARTS 

During  CAMP-2,  McDonnell  Douglas  developed  454  parts  consisting  of  over  16,000  lines  of  opera¬ 
tional  Ada  code  and  another  27,000  lines  of  Ada  test  code.  From  this  work,  we  developed  a  number  of 
conclusions  concerning  the  use  of  Ada  and  the  development  of  parts. 

Conclusion  #14 

The  use  of  Ada  results  in  improved  development  productivity. 

MDAC-STL  carefully  collected  data  concerning  the  effort  expended  and  the  resulting  size  of  the 
CAMP  parts.  This  data  shows  that  overall  productivity  for  developing  the  CAMP  parts  was  258 
LOC/MM.  One  software  cost  estimating  model,  COC’OMO,  estimated  productivity  at  160  LOC/MM. 
Section  II  of  this  volume  describes  the  productivity  analysis  for  the  CAMP  parts  development  in  greater 
detail.  We  attribute  this  increased  productivity  to  four  factors. 
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•  The  use  of  Ada 

•  The  use  of  good  people 

•  The  use  of  good  tools 

•  The  reuse  of  software 

Few  people  have  doubted  that  Ada  would  increase  the  productivity  of  the  software  maintenance 
process,  but  one  of  the  unresolved  questions  within  the  Ada  software  engineering  community  has  been 
whether  the  use  of  Ada  would  help  developmental  productivity  on  the  first  set  of  projects  on  which  it  was 
used.  We  believe  the  use  of  Ada  was  the  primary  factor  behind  our  higher  than  expected  productivity  on 
the  CAMP  parts  development  task.  In  addition  to  providing  a  complete  set  of  structured  control  con¬ 
structs  and  a  highly  readable  language,  the  Ada  package  featured  allowed  us  to  identify  clear  interfaces 
between  the  different  people  working  on  the  parts,  and  hence,  promoted  a  high  degree  of  parallelism  in 
the  parts  development. 


Conclusion  #15 

Ada's  support  for  programming-in-the-large  is  one  of  its  chief  ad¬ 
vantages  from  a  management  perspective. 

It  is  worthwhile  noting  that  one  important  reason  that  the  use  of  Ada  was  a  benefit  to  our  develop¬ 
mental  productivity  was  that  we  had  an  excellent  compiler  to  develop  the  parts  —  the  DEC  VAX  Ada 
compiler.  If  one  had  to  struggle  with  an  immature  compiler,  productivity  would  be  severely  decreased. 

Conclusion  #16 

The  use  of  strongly  typed  software  parts  has  significant  benefits  to  the 
parts  user,  but  complicates  the  development  of  parts. 

One  of  the  primary  decisions  the  CAMP  team  had  to  make  very  early  in  the  development  of  the 
CAMP  parts  was  how  extensively  to  use  data  typing.  The  chief  advantage  of  making  the  parts  strongly 
typed  was  the  high  degree  of  protection  against  misuse  of  the  parts  such  typing  would  provide.  The 
disadvantage  of  using  strong  typing  was  the  increased  complexity  of  developing  the  parts.  The  inter¬ 
actions  between  types  and  generics  are  much  more  complex  than  they  appear  to  a  casual  user  of  Ada. 

Initially,  we  had  some  doubts  about  the  use  of  strong  typing.  Was  it  worth  the  extra  effort  to  avoid 
data  typing  errors?  We  surveyed  some  of  our  on-going  missile  projects  and  asked  them  if  data  typing 
errors  were  a  problem.  Somewhat  to  our  surprise,  we  found  that  the  misuse  of  data  was  considered  to  be 
a  significant  problem  area.  Given  the  large  number  of  different  types  of  data  used  in  a  missile  applica¬ 
tions,  programmers  sometimes  made  "stupid"  mistakes  (e.g,.  mixing  radians  and  degrees)  and  these  types 
of  errors  were  frequently  not  detected  until  the  software  was  tested;  at  this  point  they  were  very  difficult 
to  isolate.  Based  on  this  information,  we  decided  to  use  strong  typing  in  the  development  of  the  CAMP 
parts.  After  all.  the  parts  would  be  developed  once,  but  used  many  times. 

Conclusion  #17 

It  costs  more  to  develop  reusable  parts  than  to  develop  customized 
software. 
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While  Conclusion  #17  is  hard  lo  quantify,  it  is  our  observation  that,  depending  on  the  experience  of 
the  part  developer,  it  costs  about  5%  to  10%  more  to  develop  good  reusable  parts  than  it  costs  to  develop 
a  customized  unit  of  software.  The  part  developer  has  to  not  only  meet  the  functional  requirements  of  a 
specific  application,  he  also  has  to  think  about  how  to  make  the  part  general  enough  for  a  set  of  applica¬ 
tions  without  losing  a  significant  degree  of  efficiency. 

Recommendation  #10 

Parts  should  he  developed  hy  a  parts  development  team  driven  by  project 
needs. 

We  envision  three  ways  in  which  parts  could  be  developed. 

•  By  projects 

•  By  an  independent  parts  development  group 

•  By  a  project-directed  parts  development  group 

The  problem  with  the  first  approach  is  that  few  projects  have  the  extra  resources  to  make  good  parts. 
The  typical  DoD  software  project  has  a  short  schedule  and  a  tight  budget,  and  few  project  managers  will 
divert  their  people  from  their  primary  task  of  meeting  the  contract  requirements.  Additionally,  the  first 
approach  does  not  allow  an  organization  to  develop  a  cadre  of  parts  development  expertise  which  will 
result  in  lower  parts  development  costs.  The  problem  with  the  second  approach  is  that,  over  time,  such  a 
group  tends  to  lose  touch  with  projects’  needs  and  will  eventually  start  producing  parts  that  no  one  wants. 
The  third  approach  is  based  on  projects  providing  the  parts  developers  with  draft  parts  and  part  needs. 
This  approach  is  the  one  we  prefer.  It  allows  an  organization  to  develop  a  cadre  of  expert  part  developers 
but  provides  direction  for  them  from  the  projects. 

Conclusion  #18 

Software  parts  for  RTE  applications  must  he  developed  to  be 
semi-abstract. 

The  developer  of  reusable  parts  for  real-time,  embedded  applications  must  be  sensitive  to  the  fact 
that  frequently  the  conceptual  elegance  of  a  part  has  lo  be  sacrificed  to  obtain  the  required  degree  of 
efficiency.  While  academicians  might  insist  that  all  parts  be  developed  as  pure  abstract  objects  (i.e.,  the 
internal  structure  is  hidden  from  the  user),  the  realities  of  RTE  applications  frequently  demand  that  a  user 
access  the  internal  structure  of  a  part.  Fortunately,  the  choice  is  not  between  an  abstract  part  and  a 
non-abstract  part.  A  design  approach  exists,  which  we  refer  to  as  semi-abstraction,  in  which  a  part 
provides  the  user  with  both  an  abstract  interface  and  a  mechanism  for  directly  accessing  the  internal 
structure.  Section  VI  of  this  volume  discusses  (hi.;  issue  in  greater  detail. 
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Conclusion  #19 

The  use  of  Ada  software  parts  can  increase  productivity. 

MDAC-STL  collected  data  on  the  effort  expended  and  the  resulting  size  of  the  1 1th  Missile  Applica¬ 
tion.  This  data  shows  that  overall  productivity  was  419  LOC/MM,  and  indicates  that  productivity  can  be 
increased  by  up  to  15%  by  using  the  CAMP  parts. 

Productivity  on  the  11th  Missile  Application  was  lowered  by  difficulties  with  Ada/1750A  compilers. 
Separate  statistics  on  the  amount  of  time  spent  trouble-shooting  (he  selected  compiler  were  not  kept,  so  it 
is  impossible  to  tell  precisely  the  effect  on  productivity.  However,  we  do  know  that,  of  153  software 
errors  found  during  testing.  96  were  compiler  errors  and  57  were  errors  in  CAMP-developed  code.  It 
seems  reasonable,  therefore,  to  assume  that  half  the  testing  time  was  spent  debugging  the  compiler.  In¬ 
corporating  this  assumption,  the  productivity  of  the  11th  Missile  development  would  rise  to  572 
LOC/MM. 

Section  III  of  Volume  II  describes  the  productivity  analysis  for  the  11th  Missile  Application  in 
greater  detail. 

5.  ON  THE  COST-EFFECTIVENESS  OF  CAPTURING  SCHEMATIC 
COMMONALITY 


Conclusion  #20 

Some  important  types  of  commonality  cannot  be  captured  in  Ada. 

Early  in  the  CAMP  program,  we  realized  that  there  were  types  of  commonality  that  existed  within 
most  domains  that  either  could  not  be  captured  using  Ada  alone,  or  could  not  be  captured  efficiently  using 
Ada  alone.  We  refer  to  this  type  of  commonality  as  schematic  commonality.  To  capture  this  type  of 
commonality  requires  a  tool  which  can  build  Ada  code  when  given  the  requirements  of  a  particular 
application.  We  refer  to  these  tools  as  schematic  component  constructors',  several  of  these  constructors 
were  built  and  used  on  CAMP.  Section  IV  describes  this  work  in  more  detail. 

Conclusion  #21 

Schematic  Component  Constructors  have  high  value. 

As  an  example  of  the  utility  of  a  schematic  component  constructor,  consider  the  case  of  the  CAMP 
Kalman  Filter  Constructor  A  novice  user  can  specify  his  requirements  for  a  new  Kalman  filler  in  about 
two  minutes  using  this  constiuctor.  It  takes  the  constructor  about  another  minute  to  generate  the  Ada 
code.  In  a  typical  situation,  the  Kalman  Filler  Constructor  will  generate  387  Ada  LOC  and  use  another 
1553  CAMP  parts  LOC.  The  bottom  line  is  that  the  user  gets  1940  LOC  for  three  minutes  of  work. 

Based  on  the  number  of  lines  of  code  generated  by  the  Kalman  Filler  Constructor  for  the  1 1th 
Missile  Application,  we  estimate  that  a  28%  productivity  improvement  could  be  obtained  just  from  using 
the  Kalman  Filter  Constructor. 


122 


Recommendation  #11 

More  research  needs  to  be  performed  to  develop  an  approach  for  build¬ 
ing  schematic  component  constructors. 

Although  we  believe  that  the  utility  of  schematic  component  constructors  is  high,  the  current  ap¬ 
proach  to  their  construction  requires  a  large  development  effort  and  the  resulting  tool  is  not  easily 
modified.  One  potential  solution  to  these  problems  is  to  develop  a  constructor-constructor,  i.e.,  a  tool  that 
would  be  capable  of  generating  a  wide  variety  of  schematic  component  constructors.  One  approach  to 
such  a  constructor-constructor  would  involve  the  use  an  interactive  Ada  pre-processor. 

6.  ON  THE  CATALOGING  OF  PARTS 

During  CAMP-2,  MDAC-STL  built  a  prototype  Ada  parts  catalog.  We  drew  two  major  conclusions 
from  this  work. 


Conclusion  #22 

Cataloged  Ada  parts  should  be  classified  by  logical  operations,  not 
physical  Ada  units 

The  CAMP  parts  catalog  was  implemented  so  that  the  basic  units  being  cataloged  were  Ada  units. 
Upon  reflection,  and  after  having  used  this  catalog,  we  believe  this  approach  has  two  significant  dis¬ 
advantages. 

•  When  viewing  parts,  the  user  gets  entire  Ada  units  and  then  has  to  locate  the  portions  of  interest; 
this  is  less  than  optimal. 

•  Too  many  entities  are  cataloged  under  the  current  scheme.  This  can  lead  to  user  frustration  and 
result  in  the  parts  not  being  used. 

We  believe  that  a  better  approach  would  have  been  to  catalog  the  logical  parts,  not  the  physical  Ada 
code  units.  For  example,  the  catalog  should  tell  the  user  that  it  has  an  entry  for  a  unbounded  LIFO  queue, 
not  that  it  has  a  package  specification  called  LIFO_QUE  and  a  package  body  with  the  same  name.  Using 
this  paradigm,  the  user  would  search  for  logical  parts  and  then,  if  needed,  the  user  could  examine  the  Ada 
structure  of  these  parts. 


Conclusion  #23 

The  taxonomy! ies )  used  by  an  Ada  parts  catalog  should  be  soft-coded. 

A  software  parts  taxonomy^  is  an  important  component  of  every  software  parts  catalog.  One  of  the 
lessons  learned  on  CAMP-2  was  that  regardless  of  the  lime  and  effort  spent  in  developing  the  (axa4,  the 
taxonomy  will  change  over  time.  No  one  can  foresee  all  possible  classes  of  parts.  Likewise,  the  distinc- 


'A  mechanism  foi  classifying  softwnie  paits 
“^Thc  calegories  into  which  parts  are  classified 
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tion  of  taxa  is  an  extremely  subjective  activity.  Given  these  factors,  we  recommend  that  software  parts 
libraries  "soft-code"  their  taxonomies  so  that  they  can  naturally  evolve  over  lime. 
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APPENDIX  A 


PARTS  DATA  BASE 

I.  INTRODUCTION  AND  BACKGROUND 

During  development  of  the  CAMP  parts,  certain  information  about  the  parts  needed  to  be  gathered 
and  reports  generated  from  this  information.  One  of  the  most  basic  needs  was  for  a  simple  listing  of  all 
the  parts,  categorized  by  their  TLCSCs.  Size  (number  of  lines  of  code)  data  was  also  needed. 

The  sizing  information  report  was  originally  produced  on  an  IBM  PC.  Two  line  count  utilities 
written  by  a  member  of  the  parts  team  provided  the  input  to  this  report.  The  first  line  counter  simply 
counted  the  number  of  lines  of  Ada  code  in  a  file.  This  soon  proved  to  be  inadequate,  however,  since 
more  detailed  information  was  needed.  There  was  a  need  for  a  separate  line  count  for  specifications  and 
bodies,  and  a  separate  count  of  CAMP  header  comments  and  comments  embedded  in  the  code.  Although 
a  single  file  often  contained  more  than  one  Ada  structure,  the  original  line  counter  only  gave  a  total  for  all 
the  Ada  structures.  An  advanced  code  counter  was  developed  that  analyzed  a  file’s  Ada  structure  and 
kept  separate  counts  for  each  Ada  structure  for  both  the  specifications  and  bodies.  Since  the  first  counter 
did  no  analyzing  of  the  Ada  structure,  it  ran  considerably  faster  and  remained  in  use  for  Ada  files  contain¬ 
ing  single  Ada  structures. 

Although  these  tools  automated  the  information  gathering,  the  information  itself  was  still  entered 
into  the  report  by  editing  the  report  file.  This  meant  that  each  time  the  parts  were  updated,  a  new  part  was 
added,  or  the  structure  of  the  parts  changed,  the  report  file  had  to  be  edited  again.  This  was  cumbersome 
because  the  formatting  had  to  be  manually  redone  every  time  the  file  was  edited.  As  a  result,  information 
changes  were  not  made  as  quickly  as  required  and  the  report  became  out  of  date. 

In  order  to  address  these  difficulties,  an  ORACLE  data  base  was  developed  to  store  this  information. 
Reports  can  now  be  generated  through  the  use  of  SQL*Report,  an  ORACLE  utility  which  allows  the 
generation  of  reports.  SQL*Forms  was  used  as  to  facilitate  data  entry. 

2.  ORACLE  RELATIONS 

ORACLE  is  a  relational  data  base  with  information  stored  in  tables.  The  parts’  sizes  were  stored  in 
two  tables.  The  first  table,  named  TLCSC,  stored  information  about  the  TLCSCs.  The  second  table, 
named  Adalevel,  stored  information  about  all  of  the  lower-level  Ada  structures.  The  information  about 
the  TLCSCs  and  lower  structures  varied  slightly,  which  is  why  separate  tables  were  created. 

The  TLCSC  relation  (table),  its  fields  and  descriptions  are  given  in  the  Table  A-l  and  the  AdaLevel 
relation,  its  fields  and  descriptions  are  given  in  Table  A-2. 
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TABLE  A-l.  COLUMNS  IN  THE  TLCSC  RELATION 


TLCSC  Relation 

Column  Name 

Description 

Partno 

This  is  the  surrogate  part  number.  Each  entry  was  assigned  an  arbitrary  number  to  be  used  as 
the  prime  key  for  that  entry. 

Tnamc 

TLCSC  name  of  the  Ada  structure 

Require 

Requirement  number  (reference  SRS) 

Type 

Type  of  Ada  structure  (procedure,  generic  package  etc.) 

Parent 

The  pari  number  of  its  parent  in  the  Ada  hierarchy.  This  uses  the  surrogate  numbering 
scheme  as  used  by  the  partno  field. 

Speccodesize 

Number  of  lines  of  specification  code 

Body  code  size 

Number  of  lines  of  body  code 

Speccomsize 

Number  of  lines  of  the  header  for  the  spec 

Bodycomsize 

Number  of  lines  of  the  body  comments 

Teste  odcsize 

Number  of  lines  of  lest  code 

P»rt 

Indicates  whether  or  not  the  entry  is  a  part 

Used 

Indicates  whether  or  not  this  entry  was  used  by  the  1  Ith  Missile  Application 

Subcategory 

Subcategory  to  which  TLCSC  belongs 

TABLE  A-2.  COLUMNS  IN  THE  ADALEVEL  RELATION 


AdaLevel  Relation 

Column  Name 

Description 

Partno 

This  is  the  surrogate  part  number.  Each  entry  was  assigned  an  arbitrary  number  to  be  used  as 
the  prime  key  for  that  entry. 

LI  name 

Ada  name  of  LLCSC  or  unit 

Require 

Requirement  number  (reference  SRS) 

Type 

Type  of  Ada  structure  (procedure,  generic  package  etc.) 

Parent 

The  part  number  of  its  parent  in  the  Ada  hierarchy.  This  uses  the  surrogate  numbering 
scheme  as  used  by  the  partno  field. 

Speccodesize 

Number  of  lines  of  the  specification  code 

Bodycodesize 

Number  of  lines  of  the  body  code 

Speccomsize 

Number  of  lines  of  the  header  for  the  specification 

Bodycomsize 

Number  of  lines  of  body  comments 

Part 

Indicates  whether  or  not  the  entry  is  a  part 

Used 

Indicates  whether  or  not  this  entry  was  used  by  the  1  Ith  Missile  Application 

Levelnum 

Hierarchy  number  for  this  unit 
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These  tables  were  used  to  generate  two  reports.  The  first  is  a  list  of  all  the  parts  divided  into  their 
source  file  components.  Along  with  this  list  is  sizing  information,  whether  it  is  a  part,  and  whether  it  was 
used  in  the  11th  Missile  Application.  The  second  report  is  a  list  of  all  the  parts  used  in  the  1 1th  Missile 
Application  and  their  respective  code  sizes.  The  second  report  is  discussed  in  the  Appendix  of  Volume  2. 

The  parts  size  report  is  contained  in  Table  A-3. 


127 


TABLE  A-3.  CAMP  PARTS  SIZING  LIST 


(1  of  14) 


TLCSC 

1  TLCSC  Name 

II 

Code  Size 

II 

Comment  Size  II 

P»rt 

1 

n  th 

II 

No. 

1  Lower  Level  Unit* 

It 

Spec 

1  Body  1 

Tent  H 

Spec 

Body  It 

1 

Uae 

II 

pool 

1  Common  Navigat ion  Part* 

n 

10 

1  10  1 

2.215  II 

215 

108  II 

N 

1 

Y 

II 

1  Altitude  Integration 

11 

12 

1  7  1 

II 

104 

137  tl 

Y 

1 

Y 

II 

1  Reinitialize 

n 

2 

1  7  1 

It 

0 

118  II 

N 

1 

Y 

II 

1  Integrate 

It 

3 

1  13  1 

II 

0 

127  H 

N 

1 

Y 

II 

1  Comptle  Ground  Velocity 

H 

10 

1  8  1 

II 

83 

107  II 

Y 

1 

Y 

II 

1  Compute  Ora  vita  tional  Acceleration  Lat  In 

II 

22 

1  13  1 

II 

119 

172  II 

Y 

1 

N 

II 

1  Compute  Gravitational  Acceleration  Sin  Lat  In 

II 

19 

1  13  1 

II 

114 

156  1! 

Y 

1 

Y 

II 

1  Compute  Heading 

II 

10 

1  6  1 

II 

84 

113  II 

Y 

1 

N 

II 

1  Update  Velocity 

II 

20 

1  8  1 

II 

135 

183  II 

Y 

1 

Y 

II 

1  Reinitia  izc 

II 

1 

1  5  1 

II 

0 

102  II 

N 

1 

Y 

It 

1  Update 

II 

4 

1  16  1 

II 

0 

172  II 

N 

1 

Y 

II 

1  Cunent  Velocity 

II 

1 

1  5  1 

II 

0 

83  It 

N 

1 

Y 

II 

1  Scalar  Velocity 

II 

9 

1  6  1 

II 

84 

101  II 

Y 

1 

N 

II 

1  Compute  Rotation  Increment* 

II 

11 

1  8  1 

11 

90 

112  II 

Y 

1 

N 

II 

SUBTOTALS 

124 

115 

2.215 

813 

1.683 

8 

9 

P002 

1  Wonder  Azimuth  Navigation  Part* 

II 

16 

16  1 

677  II 

234 

119  II 

N 

1 

Y 

II 

1  Compute  Barth  Relative  Horizontal  Velocities 

II 

16 

16  1 

II 

108 

132  II 

Y 

1 

N 

II 

1  Compute  Total  Angular  Velocity 

II 

12 

7  1 

II 

98 

118  II 

Y 

1 

N 

II 

1  Compute  Coriolis  Acceleration 

II 

19 

12  1 

II 

121 

156  II 

Y 

1 

Y 

II 

1  Total  Platform  Rotation  Rote 

H 

11 

9  1 

II 

90 

119  II 

Y 

1 

Y 

11 

1  Earth  Rotation  Rate 

II 

12 

7  1 

II 

121 

160  It 

Y 

1 

Y 

II 

1  Compute 

II 

4 

11  1 

II 

0  1 

II  II 

N 

1 

Y 

II 

1  Compute  Earth  Relative  Navigation  Rotation  Rate 

II 

18 

15  1 

II 

116  1 

170  II 

Y 

1 

Y 

tl 

1  Compute  Wander  Azimuth  Angle 

II 

12 

7  1 

II 

101  1 

125  II 

Y 

1 

N 

II 

1  Compute  l  atitude 

II 

7 

6  1 

II 

70  1 

96  N 

Y 

1 

N 

II 

1  Compute  Latitude  Using  Arctnn 

11 

16 

12  1 

II 

108  1 

141  II 

Y 

1 

N 

II 

1  Compute  Fast  Velocity  with  Sin  C  os  In 

II 

11 

13  1 

II 

97  1 

118  II 

Y 

1 

Y 

N 

1  Compute  Longitude 

II 

13 

7  1 

N 

97  1 

119  II 

Y 

1 

N 

II 

t  Compute  Curvatures 

II 

31 

30  1 

H 

13)  1 

216  H 

Y 

1 

Y 

II 

1  Compute  East  Velocity 

II 

14 

12  1 

II 

101  1 

130  H 

Y 

1 

N 

II 

1  Compute  North  Velocity 

II 

14 

12  1 

II 

101  1 

133  II 

Y 

1 

N 

N 

1  Coriolis  Acceleration  from  Total  Rates 

It 

12 

7  1 

II 

121  1 

160  N 

Y 

1 

N 

II 

1  Compute 

11 

4 

11  I 

II 

0  1 

6  II 

N 

1 

N 

If 

1  Compute  North  Velocity  with  Sin  Cos  In 

II 

11 

13  1 

II 

99  1 

123  II 

Y 

1 

Y 

II 

1  Compute  Earth  Relative  Horizontal  Velocities 

II 

1 

II 

1 

II 

1 

II 

1  With  Sin  Cos  In 

II 

13 

15  1 

II 

106  1 

119  II 

Y 

1 

N 

II 

1  Compute  Latitude  Using  Two  Value  Arctangent 

II 

14 

16  1 

II 

100  1 

119  II 

Y 

1 

Y 

II 

1  Compute  Longitude  using  Two  Value  Arctangent 

II 

11 

11  1 

II 

88  1 

105  II 

Y 

1 

Y 

II 

1  Compute  Wander  Azimuth  Angle  using  Two  Value 

II 

1 

II 

1 

II 

1 

II 

1  Arctangent 

II 

10 

12  1 

II 

92  1 

115  II 

Y 

1 

Y 

II 

SUBTOTALS 

283 

261 

677 

2.066 

2.691 

20 

1 1 

POO  3 

1  North  Pointing  Navigation  Paris 

II 

9 

9  1 

541  II 

190  1 

117  II 

N 

1 

N 

T 

1  Compute  Coriolis  Acceleration 

II 

17 

14  1 

II 

102  1 

142  II 

Y 

1 

N 

ii 

1  Total  Platform  Rotation  Rates 

II 

11 

9  1 

II 

82  1 

104  II 

Y 

1 

N 

ii 

1  Earth  Rotation  Rate 

II 

16 

7  1 

II 

114  1 

148  II 

Y 

1 

N 

ii 

1  Compute 

11 

2 

12  1 

II 

0  1 

6  II 

N 

1 

N 

n 

1  Barth  Relative  Navigation  Rotation  Rote 

II 

18 

7  1 

II 

134  1 

155  II 

Y 

1 

N 

ii 

1  Compute 

II 

4 

11  1 

II 

0  1 

6  II 

N 

1 

N 

ii 

1  Latitude  Integration 

II 

13 

6  1 

II 

100  1 

147  II 

Y 

1 

N 

ti 

1  Reinitialize 

II 

2 

7  1 

II 

0  1 

121  II 

N 

1 

N 

ti 

1  Integrate 

H 

3 

12  1 

II 

0  1 

131  II 

N 

1 

N 

H 

1  Longitude  Integration 

II 

18 

43  1 

II 

112  1 

164  II 

Y 

1 

N 

II 

1  Reinitialize 

II 

3 

8  1 

II 

0  1 

134  II 

N 

1 

N 

II 

1  Integrate 

II 

4 

16  1 

II 

0  1 

149  II 

N 

1 

N 

II 

1  Radius  of  Curvature 

II 

25 

7  1 

II 

127  1 

193  H 

Y 

1 

N 

II 

1  Compute 

II 

2 

25  1 

II 

0  1 

6  11 

N 

1 

N 

II 

SUBTOTALS 

138 

184 

541 

771 

1.606 

7 

0 

P36I 

1  General  Utilities 

II 

3  1 

3  1 

0  II 

69  1 

63  It 

N 

7" 

N 

II 

1  Instruction  Set  Test 

II 

6  1 

6  I 

II 

75  1 

90  II 

Y 

i 

N 

It 

subtotals 

6 

6 

0 

75 

90 

1 

0 

P60I 

1  Asynchronous  Control 

II 

2  1 

0  1 

0  II 

0  1 

0  II 

Y 

i 

N 

II 

1  Data  Driven  Task  Shell 

II 

2  1 

0  1 

II 

0  1 

0  II 

N 

i 

N 

II 

128 


TABLE  A-3.  CAMP  PARTS  SIZING  LIST  (2  OF  14) 


TLCSC 

No, 

TLCSC  Nome 

Lower  Level  Units 

N 

II 

Spec 

Code  Sire 

1  Body  1 

II 

Teat  K 

Comment  Size  If 
Spec  1  Body  8 

Pari 

Uth 

Uae 

II 

It 

Interrupt- Driven  Task  Shell 

II 

5 

1 

0  1 

II 

0  1 

0  II 

N 

N 

n 

Aperiodic  Task  Shell 

II 

3 

1 

0  1 

It 

0  1 

0  II 

N 

N 

Q 

Continuous  Tank  Shell 

II 

□ 

H 

0  1 

II 

0  1 

0  II 

N 

N 

Periodic  Tnsk  Shell 

II 

m 

9 

0  1 

II 

0  1 

0  II 

N 

N 

Q 

SUBTOTALS 

15 

0 

0 

0 

0 

0 

P602 

Communication  Ports 

II 

3 

3  f 

296  II 

81  1 

73  II 

N 

N 

II 

Update  Exclusion 

II 

9 

3  1 

It 

126  1 

95  N 

Y 

N 

II 

Rend  Updnte 

II 

3 

29  1 

II 

0  1 

0  11 

N 

N 

II 

Attrmpt  Rend 

II 

2 

10  1 

II 

0  1 

0  II 

N 

N 

II 

Attempt  Read  Wail 

II 

2 

6  1 

II 

0  1 

0  II 

N  1 

N 

II 

Attempt  Rend  Delny 

II 

3 

12  1 

II 

0  1 

0  II 

N  1 

N 

II 

Attempt  Start  Update 

II 

3 

13  1 

II 

0  1 

0  II 

N  1 

N 

II 

Attempt  Start  Updnte  Wait 

II 

3 

8  1 

II 

0  1 

0  II 

N  1 

N 

It 

Attempt  Stnrt  Updnte  Delny 

II 

4 

14  1 

If 

0  1 

0  1 

N  1 

N 

II 

Attempt  Complete  Update 

II 

3 

15  1 

II 

0  1 

0  II 

N  1 

N 

II 

SUBTOTALS 

34 

110 

296 

ns 

95 

1 

0 

P61  1 

WGS72  Ellipsoid  Metric  Data 

II 

29 

0  1 

96  fl 

121  1 

0  H 

Y  1 

M 

If 

P6I2 

WOS72  Ellipsoid  Engineering  Data 

II 

30 

0  1 

92  II 

143  1 

0  H 

Y  1 

M 

T 

P6I3 

WG372  Ellipsoid  Unitless  Data 

It 

11 

<rr 

160  fl 

70  1 

ft 

Y  1 

Y 

n 

P6I4 

Conversion  Factors 

II 

41 

0  1 

200  II 

121  1 

o  n 

Y  1 

Y 

ii 

P6I5 

Universal  Constants 

II 

9 

0  1 

129  H 

72  1 

0  1 

Y  1 

Y 

T 

P62I 

B«k  Data  Type! 

II 

133 

113  1 

331  K 

182  1 

436  n 

Y  1 

M 

n 

P622 

Kalman  Filter  Data  Types 

n 

213 

40  1 

186  II 

317  1 

127  II 

Y  1 

N 

ii 

P623 

Autopilot  Data  Types 

ii 

nn 

92  1 

267  II 

145  1 

228  fl 

Y  1 

N 

H 

P631 

Missile  Radar  Altimeter  Handler  Part* 

ii 

15 

25  1 

0  II 

220  1 

3  fl 

Y  1 

N 

T 

Power  On 

H 

l 

22  1 

N 

0  1 

17  n 

N  1 

N 

ii 

Power  Off 

ii 

i 

4  1 

II 

0  1 

o  n 

N  1 

N 

H 

Ooto  Transmit  Mode 

ii 

i 

4  1 

II 

0  1 

0  It 

N  1 

N 

It 

Ooto  Standby  Mode 

ii 

i 

4  1 

ft 

0  1 

0  II 

N  1 

N 

II 

Perform  Built  In  Test 

ii 

4 

7  1 

II 

0  1 

0  H 

N  1 

N 

II 

Perform  Built  In  Test  Sequence 

it 

4 

7  1 

II 

0  1 

0  II 

N  1 

N 

II 

Read  Altitude  Feet 

ii 

4 

7  1 

II 

0  1 

0  If 

N  1 

N 

II 

Read  Altitude  Integer 

ii 

4 

7  1 

II 

0  1 

0  fl 

N  1 

N 

II 

SUBTOTALS 

20 

62 

0 

0 

17 

0 

0 

P632 

Missile  Rodar  Altimeter  Handier  Auto 

ii 

15 

25  1 

0  II 

190  1 

1  II 

Y  1 

N 

II 

Goto  Transmit  Mode 

ii 

1 

22  1 

H 

0  1 

17  II 

N  1 

N 

II 

Ooto  Standby  Mode 

ii 

1 

4  1 

It 

0  1 

0  II 

N  1 

N 

II 

Perform  Built  In  Test 

ii 

4 

7  1 

II 

0  1 

0  11 

N  1 

N 

II 

Perform  Built  In  lest  Sequence 

ii 

4 

7  1 

II 

0  1 

0  11 

N  1 

N 

II 

Rend  Altitude  Feet 

ii 

4 

7  1 

II 

0  1 

r>  II 

N  1 

N 

II 

Read  Altitude  Integer 

ii 

4 

7  1 

H 

0  1 

0  II 

N  t 

N 

II 

SUBTOTALS 

18 

54 

0 

0 

17 

0 

P633 

Bus  Interface  Ports 

ii 

6 

0  1 

0  II 

229  1 

0  II 

Y  1 

M 

T 

Send  Message  Using  Address  No  Wait 

ii 

4 

0  1 

n 

0  1 

0  II 

N  1 

N 

n 

Send  Message  Using  Address  Wait 

ii 

5 

0  1 

ii 

0  1 

0  II 

N  1 

N 

ii 

Data  Transfer  No  Wail 

n 

5 

0  1 

ii 

0  1 

0  II 

N  1 

N 

ii 

Data  Transfer  Walt 

ii 

6 

0  1 

n 

0  1 

0  II 

N  1 

N 

it 

Perform  Built  In  Te*i 

ii 

3 

0  1 

ii 

0  1 

0  II 

Is  1 

N 

n 

Interface 

ii 

18 

0  1 

it 

6  1 

0  II 

N  1 

N 

n 

Update  Retry  Count 

Ii 

1 

0  1 

ii 

0  1 

0  II 

N  1 

N 

ii 

Send  C'ommnnd  Wait 

II 

3  1 

0  1 

ii 

0  1 

0  II 

N  1 

N 

ii 

129 


TABLE  A-3.  CAMP  PARTS  SIZING  LIST  (3  OF  14) 


TLCSC 

1 

TLCSC  N.mc 

II 

Code  Size 

II 

Comment  Size 

II 

Part 

I 

lllh 

II 

No. 

1 

Lower  Level  Units 

H 

Spec 

1  Body  1 

Test  8 

Spec  1 

Body 

II 

1 

Use 

II 

1 

Send  Message  No  Wait 

II 

4 

1  0  1 

N 

0  1 

0 

II 

N 

| 

M 

II 

1 

Send  Message  Wait 

II 

5 

1  0  1 

" 

0  1 

0 

II 

N 

1 

N 

II 

SUBTOTALS 

54 

0 

0 

6 

0 

0 

0 

”634 

1 

Clock  Handler 

II 

J 

1  11  1 

203  II 

132  t 

121 

It 

V 

1 

Y 

II 

I 

Current  Time 

II 

1 

1  5  1 

8 

6  1 

98 

N 

N 

1 

Y 

II 

1 

Converted  Time 

»l 

2 

1  6  1 

« 

0  1 

103 

a 

N 

1 

N 

li 

1 

Reset  (lock 

II 

1 

1  5  1 

a 

0  i 

94 

a 

N 

1 

N 

II 

1 

Synchronize  Clock 

n 

J 

1  7  t 

a 

0  1 

99 

a 

N 

1 

Y 

II 

1 

Elapsed  Time 

II 

1 

1  9  1 

a 

0  1 

M2 

a 

N 

1 

N 

II 

SUBTOTALS 

8 

32 

203 

0 

506 

0 

2 

P644 

1 

Direction  Cosine  Matrix  Operations 

II 

5 

5  1 

341  II 

158  1 

103 

ll 

N 

Y 

II 

i 

DCM  Oeneral  Operations 

II 

m 

H  1 

II 

86  1 

92 

II 

N 

Y 

II 

1 

DCM  Initialized  From  Reference 

II 

23 

62  1 

II 

203  1 

221 

ll 

Y 

Y 

II 

1 

DCM  Trapezoidal  Integration 

II 

26 

7  1 

II 

205  1 

201 

ll 

y 

N 

II 

1 

Reinitialize  Angular  Velocities 

II 

3 

8  1 

II 

0  1 

129 

ll 

N 

N 

II 

1 

Perform_Trapezoidal_lntegratlon  of  DCM 

II 

5 

44  1 

II 

0  1 

253 

ll 

N 

N 

II 

1 

Perform  Rectangular  Integration  of  DCM 

II 

24 

27  1 

II 

174  1 

199 

it 

Y 

Y 

II 

1 

Reorthonormalize  DCM 

II 

23 

33  1 

II 

169  1 

184 

ll 

Y 

Y 

II 

1 

Frame  Misalignment 

II 

29 

18  1 

II 

188  1 

194 

ll 

Y 

Y 

II 

1 

Aligned  DCM  Matrix 

II 

29 

26  1 

II 

186  1 

213 

ll 

Y 

Y 

II 

1 

DCM  From  Quaternion 

II 

26 

37  1 

II 

167  1 

193 

ll 

Y 

Y 

II 

1 

Compute  First  Row  from  Orthonormal 

II 

16 

n  i 

If 

141  1 

135 

ll 

Y 

Y 

II 

1 

CNE  Operations 

It 

29 

26  1 

II 

227  1 

213 

ll 

N 

Y 

II 

1 

Reorthonormalize  CNE 

II 

1 

4  1 

II 

n  i 

0 

H 

Y 

Y 

II 

1 

CNE  Initialized  Front  Enrth  Position 

It 

15 

28  1 

II 

116  1 

157 

ll 

Y 

Y 

II 

1 

CNE  Integration 

II 

14 

21  1 

II 

135  1 

233 

ti 

Y 

Y 

II 

I 

Perform  Trapezoidal  Integration  of  CNE 

II 

5 

9  1 

II 

0  1 

0 

ll 

N 

Y 

II 

1 

Reinit  Ang  Vel  For  Trapez  Integ  of  CNE 

II 

3 

8  1 

(1 

0  1 

0 

ll 

N 

Y 

II 

1 

Perform  Rectangular  Integration  of  CNE 

II 

5 

7  1 

II 

0  1 

0 

ll 

N 

Y 

II 

1 

Alignment  Parts 

II 

18 

21  1 

II 

160  1 

205 

ll 

Y 

Y 

II 

1 

Frame  Misalignment  of  CNE 

II 

4 

7  1 

II 

0  1 

0 

ll 

N 

Y 

II 

1 

Aligned  CNE  Matrix 

II 

4 

7  1 

II 

0  1 

0 

ll 

N 

Y 

II 

I 

CNE  From  Quaternion 

II 

13 

II  1 

II 

140  1 

160 

ll 

Y 

Y 

II 

I 

Compute  CNE 

II 

3 

6  1 

1! 

0  1 

0 

it 

N 

Y 

II 

1 

Compute  Fir-*!  Row  of  CNE  Front  Orthonormal 

II 

2 

5  1 

II 

0  1 

0 

n 

Y 

Y 

II 

1 

CNE  Initialized  From  Reference 

II 

8 

17  1 

II 

0  1 

0 

n 

Y 

Y 

II 

SUBTOTALS  339  461  541  2.297  2.9*2  15  22 


P651 

1 

Kalman  Filter  Common  Parts 

II 

6  1 

6  ! 

40f>  a 

116  I 

63 

II 

N  1 

Y 

II 

1 

State  Transition  And  Process  Noise  Matrices 

II 

1 

I 

a 

1 

H 

| 

a 

1 

Manager 

II 

31  1 

10  1 

ii 

142  1 

140 

a 

Y  1 

Y 

a 

1 

Initialize 

II 

1  1 

6  1 

ii 

0  1 

91 

a 

N  l 

Y 

a 

1 

Propagate 

II 

3  1 

10  1 

a 

0  1 

130 

a 

N  1 

Y 

» 

1 

Gel  Current 

II 

3  1 

7  1 

a 

0  1 

101 

a 

N  1 

Y 

a 

1 

Propagated^Phi 

II 

i  • 

5  1 

a 

0  t 

90 

a 

N  I 

Y 

a 

1 

Error  Covariance  Matrix  Manager 

II 

15  1 

a  i 

a 

97  1 

no 

it 

V  1 

V 

it 

1 

Initialize 

II 

1  * 

5  1 

a 

0  1 

ao 

a 

N  1 

Y 

ii 

1 

Propagate 

II 

2  1 

6  1 

a 

0  1 

98 

a 

N  1 

Y 

a 

1 

P 

II 

1  1 

N 

0  1 

79 

ii 

N  1 

Y 

ii 

1 

State  Transition  Matrix  Manager 

li 

m  i 

8  1 

a 

95  1 

104 

n 

Y  1 

N 

a 

1 

Propagated_Phi 

N 

i  i 

5  1 

a 

0  1 

90 

a 

N  1 

N 

a 

1 

Initialize 

II 

1  1 

5  1 

ii 

0  1 

73 

a 

N  1 

N 

a 

f 

Propagate 

II 

i  i 

5  1 

a 

0  1 

93 

a 

N  1 

N 

■ 

SUBTOTALS 

72 

83 

406 

334 

1,279 

3 

9 

P652 

1 

Kalman  Filter  Compact  H  Parts 

II 

8  1 

25  1 

462  II 

136  1 

69 

ii 

N  1 

Y 

ti 

1 

Compute  Kalinan  Gain 

II 

19  1 

18  1 

ll 

96  1 

100 

ii 

Y  1 

Y 

n 

1 

Update  Eiror  Covarinnce  Matrix 

II 

22  1 

12  1 

II 

96  1 

99 

ii 

Y  1 

N 

ii 

1 

Update  Stale  Vector 

II 

20  1 

13  1 

II 

95  1 

94 

ii 

Y  1 

Y 

n 

1 

Sequentially  Update  Covariance  Matrix  and  State 

II 

1 

1 

II 

1 

ii 

1 

ii 

1 

Vector 

II 

30  1 

28  1 

II 

117  1 

134 

n 

Y  1 

N 

ii 

1 

IJpdntc 

II 

6  1 

24  1 

II 

0  1 

104 

ii 

N  1 

N 

ii 

130 


TABLE  A-3.  CAMP  PARTS  SIZING  LIST  (4  OF  14) 


Tt.CSC  1 

TLCSC  Name 

II 

Code  Size 

ii 

Comment  Size  8 

Part  1 

llth 

II 

No. 

1 

Lower  Level  Unit* 

II 

Spec 

1  Body 

Test  II 

Spec 

Body  N 

1 

Uae 

II 

t 

Kalman  Update 

n 

44 

1  21 

II 

147 

162  n 

Y  1 

N 

8 

1 

Update 

II 

8 

1  23 

II 

0 

117  II 

N  1 

N 

II 

1 

Update  Error  Covariance  Matrix  General  Form 

II 

29 

1  17 

II 

123 

128  II 

HH 

■a 

SUBTOTALS 

17* 

156 

462 

674 

938 

JUI 

m 

■ 

P653 

Kalman  Filter  Complicated  H  Parts 

II 

9 

21 

457  II 

130 

72  It 

RH 

H 

n 

Compute  Kalman  Gain 

II 

30 

20 

II 

113 

123  II 

Y  1 

11 

Update  Error  Covariance  Matrix 

II 

23 

13 

n 

ItO 

113  II 

Y  1 

N 

n 

Update  State  Vector 

II 

26 

14 

ii 

105 

110  II 

Y  1 

Y 

Bj 

Sequentially  Update  Covariance  Matrix  and  State 

II 

8 

It 

1 

8 

Vector 

H 

40 

32 

II 

134 

136  II 

Y  1 

N 

8 

Update 

II 

6 

24 

8 

0 

106  8 

N  1 

N 

II 

Kalman  Updote 

8 

53 

20  1 

H 

161 

182  8 

Y  1 

N 

II 

Update 

II 

7 

22  i 

II 

0 

112  8 

N  1 

N 

8 

Update  Error  Covariance  Matrix  General  Form 

H 

35 

17  1 

11 

126 

126  8 

Y  1 

Y 

II 

SUBTOTALS 

222 

162 

437 

749 

1.028 

6 

3 

P661 

1 

Waypoint  Steering 

It 

13 

28  1 

1.022  II 

176 

103  8 

N  1 

Y 

II 

1 

Distance  to  Current  Waypoint 

II 

15 

II  1 

II 

III 

116  8 

Y  1 

N 

II 

1 

Compute  Turning  and  Non  turning  Distance* 

II 

12 

14  1 

II 

96 

129  II 

Y  1 

Y 

II 

1 

Turn  Teat  Operation* 

II 

5 

14  1 

N 

85 

93  H 

Y  1 

Y 

II 

1 

Stop  Teat 

II 

4 

13  1 

II 

0 

110  8 

N  1 

Y 

II 

1 

Start  Test 

II 

4 

13  1 

II 

0 

104  8 

N  1 

Y 

8 

1 

Steering  Vector  Operation- 

H 

22 

40  1 

8 

170 

176  8 

Y  1 

N 

8 

1 

Initialize 

II 

12 

41  1 

n 

0 

174  H 

N  1 

N 

II 

1 

Update 

II 

n 

24  1 

ii 

0 

150  8 

N  1 

N 

8 

1 

Steering  Vector  Operations  with  Aicsin 

n 

24 

23  1 

8 

174  I 

167  II 

Y  1 

Y 

8 

1 

Initialize 

n 

12 

40  1 

8 

0  1 

171  8 

N  1 

Y 

II 

1 

Update 

ii 

8 

23  1 

8 

0  1 

147  8 

N  1 

Y 

II 

1 

Compute  Turn  Angle  and  Direction 

ii 

18 

24  1 

8 

116  1 

155  8 

Y  1 

Y 

It 

1 

CroaatTBck  and  Heading  Bitot  Operations 

n 

37 

33  1 

8 

187  1 

169  H 

Y  1 

Y 

II 

1 

r ompute  When  not  Turning 

n 

6 

23  1 

8 

0  1 

185  II 

N  1 

N 

II 

1 

Compute 

ii 

12 

36  1 

8 

0  1 

158  8 

N  1 

N 

II 

1 

Compute  When  Turning 

if 

11 

43  1 

8 

0  1 

228  If 

N  1 

Y 

II 

1 

Distance  to  Current  Waypoint  with  Arcsin 

n 

19 

II  1 

11 

117  1 

150  H 

Y  1 

Y 

II 

SUBTOTALS 

229 

426 

1.022 

1.056 

2.582 

8 

11 

P662 

Autopilot 

8 

3 

6  1 

2.533  II 

146  1 

64  !! 

N  1 

Y 

II 

Integral  Plus  Proportional  Gain 

II 

12 

7  1 

8 

113  1 

ioo  :» 

Y  1 

N 

It 

Integrate 

II 

1 

5  1 

N 

0  1 

141  II 

N  1 

N 

II 

Update  Proportional  Gain 

It 

1 

3  1 

II 

0  1 

112  II 

N  1 

N 

II 

Pitch  Autopilot 

II 

47 

31  1 

11 

233  1 

143  II 

Y  1 

N 

II 

Initialize  Pitch  Autopilot 

II 

5 

21  1 

It 

0  1 

138  II 

N  1 

N 

II 

Compute  Elevator  C  ommand 

II 

0 

23  1 

8 

0  1 

151  8 

N  1 

N 

II 

Update  Pitch  Rate  Onin 

n 

0 

5  1 

II 

0  1 

89  II 

N  1 

N 

II 

Update  Acceleration  Oain 

H 

0 

5  1 

8 

0  1 

91  II 

N  1 

N 

II 

Update  Integrator  Onin 

II 

0 

5  1 

8 

0  1 

98  II 

N  1 

N 

II 

Update  Integrator  Limit 

II 

0 

3  1 

8 

0  I 

98  II 

N  1 

N 

II 

Update  Proportional  Gain 

II 

2 

7  1 

8 

0  1 

99  II 

N  1 

N 

II 

Lateral  Directional  Autopilot 

II 

64 

39  1 

8 

392  1 

251  II 

Y  1 

N 

II 

Initialize  Lateral  Directional  Autopilot 

II 

10 

38  1 

II 

0  1 

207  II 

N  1 

N 

II 

t 'ompute  Aileron  Rudder  Commands 

II 

9 

42  1 

8 

0  1 

230  II 

N  1 

N 

II 

Update  Aileron  Integrator  Gain 

II 

2 

6  1 

II 

0  1 

96  II 

N  1 

N 

II 

Update  Aileron  Integrator  Limit 

II 

2 

7  1 

II 

0  1 

99  II 

N  1 

N 

II 

Update  Roll  Command  Proportional  Oain 

II 

2 

6  1 

II 

0  1 

97  II 

N  1 

N 

II 

Update  Roll  Rate  Oain  For  Aileron 

N 

2 

6  1 

8 

0  1 

91  8 

N  1 

N 

8 

Update  Yaw  Rate  Onin  For  Aileron 

II 

2 

6  1 

II 

0  1 

91  II 

N  1 

N 

II 

Update  Rudder  Integrator  Oain 

It 

2 

6  1 

H 

0  1 

98  II 

N  1 

N 

II 

Update  Rudder  Integrator  Limit 

II 

2  1 

7  1 

8 

0  1 

98  II 

N  1 

N 

II 

Update  Feedback  Rate  Oain  For  Rudder 

II 

2  1 

6  1 

II 

0  1 

91  II 

N  1 

N 

II 

Update  Roll  Rate  Gain  For  Rudder 

II 

2  1 

6  1 

8 

0  1 

91  II 

N  1 

N 

tl 

Update  Acceleration  Proportional  Oain 

It 

2  1 

6  1 

II 

0  1 

98  II 

N  1 

N 

II 

SUBTOTALS 

171 

320 

2.533 

740 

2.898 

3 

0 

131 


TABLE  A-3.  CAMP  PARTS  SIZING  LIST  (5  OF  14) 


ncsc 

1 

TLCSC  Name 

II 

Code  Sire 

II 

Comment  Size 

II 

Pwt 

11th 

tl 

No. 

1 

I^ower  Level  Units 

W 

Spec 

1  Body  1 

Teat 

H 

Spec  1 

Body 

II 

Uae 

II 

P67I 

T 

Air  Data  Parts 

II 

9 

1  23  1 

288 

T 

90  1 

61 

II 

N 

N 

II 

i 

Compute  Outside  Air  Temperature 

II 

16 

1  9  1 

II 

100  1 

99 

II 

Y 

N 

II 

i 

Compute  Pressure  Ratio 

n 

12 

1  II  1 

II 

92  1 

90 

II 

Y 

N 

II 

i 

Compute  Mach 

h 

12 

1  6  1 

II 

95  1 

94 

II 

Y 

N 

II 

i 

Compute  Dynamic  Pressure 

it 

fl 

1  9  1 

II 

85  1 

85 

II 

Y 

N 

II 

i 

Compute  Speed  of  Sound 

n 

13 

1  7  1 

II 

91  1 

93 

II 

Y 

N 

II 

i 

Barometric  Altitude  Integration 

if 

19 

1  ft  1 

II 

115  1 

108 

II 

Y 

N 

II 

i 

Compute  Barometric  Altitude 

ii 

4 

1  27  1 

II 

0  1 

121 

II 

N 

N 

II 

SUBTOTALS 

87 

77 

288 

578 

690 

6 

0 

P672 

i 

Fuel  Control  Parts 

it 

4 

1  6  1 

402 

II 

84  1 

71 

II 

N 

N 

II 

i 

Throttle  Command  Manager 

ii 

20 

1  62  1 

n 

117  1 

211 

II 

Y 

N 

II 

i 

Compute  Throttle  Command 

H 

4 

1  17  1 

ii 

0  1 

117 

II 

N 

N 

II 

i 

Update  Mach  Em>r  Limit 

ii 

2 

1  S  1 

ii 

0  1 

81 

tl 

N 

N 

II 

i 

Update  Mach  Error  Integral  l  imit 

ii 

2 

1  6  1 

n 

0  I 

82 

II 

N 

N 

II 

i 

Update  Throttle  Rate  Limit 

ii 

2 

1  6  I 

0 

0  1 

82 

II 

N 

N 

II 

i 

Update  Throttk  Command  Limits 

it 

3 

1  8  1 

n 

0  1 

84 

II 

N 

N 

M 

i 

Update  Mach  Error  Oain 

ii 

2 

1  3  1 

ii 

0  1 

80 

II 

N 

N 

11 

i 

Update  Ttwoftle  Bandwidth 

ii 

2 

1  6  1 

n 

0  1 

82 

II 

N 

N 

II 

SUBTOTALS 

37 

113 

402 

117 

819 

1 

0 

P6«l 

Coordinate  Vector  Matrix  Algebra 

II 

10  1 

17 

«58  II 

109 

94  II 

N 

Y 

II 

Matrix  Operations 

II 

8  1 

20 

il 

101 

90  H 

N 

N 

II 

N 

2  1 

16 

II 

0 

70  II 

Y 

N 

II 

.... 

II 

2  1 

16 

|| 

0 

70  II 

Y 

N 

II 

'V 

(1 

2  1 

16 

II 

0 

72  II 

Y 

N 

II 

11 

2  1 

16 

II 

0 

72  II 

Y 

N 

II 

Set  to  Identity  Matrix 

II 

1  1 

6  1 

II 

0 

50  II 

Y 

N 

II 

Set  to  Zero  Matrix 

II 

t  1 

6  1 

II 

0 

51  II 

Y 

N 

II 

Vector  Scalar  Operations 

II 

14  1 

9  1 

N 

135 

107  II 

N 

Y 

II 

"*  " 

II 

2  1 

10  1 

II 

0  1 

105  II 

Y 

Y 

II 

Sparse_X__Vector_Scalar_Multiply 

II 

3  1 

II  1 

II 

0  1 

121  II 

Y 

N 

II 

N 

2  1 

10  1 

II 

0  1 

110  II 

Y 

Y 

Q 

Matrix  Scalar  Operations 

II 

M  1 

9  1 

il 

116  1 

69  It 

N 

N 

It 

••••' 

It 

2  1 

16  1 

n 

0  1 

72  II 

Y 

N 

II 

r 

H 

2  1 

16  1 

R 

0  1 

71  n 

Y 

N 

II 

Cross  Product 

II 

14  1 

M  1 

it 

12ft  1 

75  II 

Y 

Y 

II 

Matrix  Vector  Multiply 

II 

16  1 

22  1 

n 

124  1 

74  II 

Y 

N 

II 

Matrix  Matrix  Multiply 

II 

14  1 

39  1 

n 

110  1 

79  II 

Y 

N 

II 

Vector  Operations 

II 

ii  i 

21  1 

ii 

130  1 

165  II 

N 

Y 

II 

Sparse_Right_XY  Subtract 

II 

2  1 

10  1 

ii 

0  1 

111  II 

Y 

Y 

II 

Set_lo  Zero  Vector 

II 

1  1 

5  1 

n 

0  1 

98  II 

Y 

N 

II 

II 

2  1 

10  1 

ii 

0  ! 

115  II 

Y 

Y 

II 

11 

2  1 

10  1 

it 

0  1 

114  II 

Y 

Y 

II 

Vector_Length 

II 

I  1 

5  1 

ii 

0  1 

111  II 

Y 

N 

II 

Dot  Product 

H 

2  1 

10  1 

ii 

0  1 

112  II 

Y 

Y 

II 

Spnrse_Right  Add 

If 

2  1 

10  1 

H 

0  1 

112  II 

Y 

Y 

II 

Sparse  Right_X  Add 

II 

2  1 

10  1 

II 

0  1 

111  II 

Y 

N 

II 

SUBTOTALS 

126 

343 

838 

844 

2,407 

MM 

10 

P6»2 

1 

Oeneral  Vector  Matrix  Algebra 

n 

33  1 

43  1 

3.792  II 

447  1 

177  II 

N  1 

Y 

II 

1 

ABA_Trana_Dynem„Sparse  Matrix _Sq  Matrix 

ii 

16  1 

50  1 

n 

133  1 

148  II 

N  1 

N 

II 

1 

ABA„Transpose 

ii 

3  1 

12  1 

n 

0  1 

6  n 

Y  1 

N 

11 

1 

ABA  Trans  Vector  Sq  Matrix 

« 

16  1 

33  1 

it 

121  1 

139  II 

N  1 

N 

H 

1 

ABA_Transpose 

ii 

2  1 

n  i 

it 

0  1 

6  II 

Y  1 

N 

II 

1 

ABA  Trans  Vector  Scalar 

n 

14  1 

41  1 

ii 

120  1 

164  II 

N  1 

N 

II 

1 

ABATranspose 

n 

2  1 

10  1 

it 

0  1 

6  II 

Y  1 

N 

II 

1 

Column  Matrix_Operations 

ii 

12  1 

7  1 

ii 

123  1 

100  II 

N  1 

Y 

II 

1 

Set_DiagonaL  and_SuhtTact_from_ldentity 

ii 

3  1 

17  1 

ii 

0  1 

93  II 

Y  1 

Y 

11 

1 

ABA_Transpose 

ii 

9  1 

33  1 

n 

0  1 

121  It 

Y  1 

N 

II 

1 

ABA  Symm_Trnnsposc 

ii 

9  1 

37  1 

ii 

0  1 

133  II 

Y  1 

Y 

II 

1 

Dot  Product  Operations  Unrestricted 

ii 

13  1 

V  1 

ii 

131  1 

120  II 

N  1 

N 

II 

1 

Dot  Product 

ii 

2  1 

19  1 

ii 

0  1 

102  II 

Y  1 

N 

II 

1 

Dot  Product  Operations  Restricted 

ii 

13  1 

14  1 

ii 

118  1 

115  II 

Y  1 

N 

II 

1 

Diagonal  '•ull  Matrix  Add  Unrestricted 

ii 

15  1 

12  1 

ii 

149  1 

118  II 

N  1 

N 

II 

1 

’V 

ii 

2  1 

38  1 

ii 

0  1 

135  II 

Y  1 

N 

II 

1 

Diagon  .1  Full  Matrix  Add  Restricted 

n 

10  1 

21  1 

ii 

112  1 

103  II 

Y  1 

Y 

II 

132 


TLCSC 

No. 


TABLE  A-3.  CAMP  PARTS  SIZING  LIST  (6  OF  14) 


TLCSC  Nime 

Lower  Level  Units 

II 

n 

Spec 

Code  Size 

1  Body  1 

If 

Test  11 

Comment  Size  II 
Spec  1  Body  H 

Part 

1 

1 

11th 

Use 

II 

II 

Matrix  Scalar  Operations  Constrained 

n 

15 

5  1 

11 

135 

97  n 

N 

1 

N 

II 

ii 

2 

14  1 

II 

0 

107  II 

Y 

1 

N 

II 

r 

If 

2 

14  1 

II 

0 

109  N 

Y 

1 

N 

H 

Diagonal  Matrix  Scalar  Operations 

II 

15 

II  1 

II 

182 

113  II 

N 

1 

Y 

II 

II 

2 

14  1 

II 

0 

104  II 

Y 

1 

Y 

II 

T 

II 

2 

It  1 

II 

0  1 

97  II 

Y 

1 

N 

1 

Matrix  Vector  Multiply  UnreatTicted 

II 

21 

10  1 

II 

275  1 

149  It 

N 

1 

N 

II 

H 

2 

31  1 

It 

0  1 

133  fl 

Y 

1 

N 

II 

Matrix  Vector  Multiply  Restricted 

II 

19 

It  1 

II 

252  1 

121  II 

Y 

1 

N 

H 

Vector  Matrix  Multiply  Unrestricted 

(1 

2! 

10  1 

H 

273  1 

160  N 

N 

1 

N 

H 

H 

2 

27  1 

II 

0  1 

6  N 

Y 

1 

N 

fl 

Vector  Matrix  Multiply  Restricted 

II 

19 

16  1 

It 

254  1 

130  fl 

Y 

1 

N 

II 

Vector  Vector  Transpose  Multiply  Unrestricted 

II 

20 

10  1 

N 

155 

136  fl 

N 

1 

N 

N 

"a" 

n 

2 

2t  1 

N 

0  1 

129  II 

Y 

1 

N 

n 

Vector  Vector  Transpose  Multiply  Restricted 

ii 

16 

16  1 

n 

136  1 

113  II 

Y 

1 

Y 

ii 

Matrix  Matrix  Multiply  Unrestricted 

ii 

25 

II  1 

n 

266  1 

147  II 

N 

1 

N 

N 

ii 

2 

41  1 

ii 

0  1 

141  N 

Y 

1 

N 

ii 

Matrix  Matrix  Multiply  Restricted 

ii 

18 

20  1 

ii 

240  1 

123  fl 

Y 

1 

Y 

ii 

Matrix  Matrix  Transpose  Multiply  Unrestricted 

ii 

23 

II  1 

ii 

150  1 

113  N 

N 

1 

N 

ii 

ii 

2 

41  1 

ii 

0  1 

140  M 

Y 

1 

N 

H 

Matrix  Matrix  Transpose  Multiply  Restricted 

ii 

16 

21  1 

ii 

131  1 

117  II 

Y 

1 

Y 

II 

Symmetric  Full  Storage  Matrix  Operations 

H 

1 

ii 

1 

H 

1 

II 

Constrained 

11 

8 

15  1 

n 

124  1 

102  H 

N 

1 

Y 

II 

Change  Element 

II 

4 

17  1 

n 

0  1 

III  H 

Y 

1 

N 

II 

SeMo.  Idcnt  |ty_  Matrix 

11 

1 

16  1 

ii 

0  1 

101  N 

Y 

1 

N 

II 

Set_  to_Zer  o_Matr  i  x 

H 

1 

3  1 

N 

0  1 

83  N 

Y 

1 

Y 

It 

Add.to  Identity 

II 

1 

It  1 

11 

0  1 

100  N 

Y 

1 

N 

II 

Subtract  from.ldentjty 

II 

1 

21  1 

II 

0  1 

131  H 

Y 

1 

N 

It 

*V 

N 

2 

30  1 

II 

0  1 

126  H 

Y 

1 

Y 

II 

...» 

II 

2 

30  1 

11 

0  1 

126  fl 

Y 

1 

N 

II 

Diagonal  Matrix  Operations 

H 

13 

47  1 

II 

153  1 

200  II 

N 

1 

N 

II 

Identity.  Matrix 

fl 

1 

3  1 

II 

0  1 

95  H 

Y 

1 

N 

II 

Zero.Matrix 

n 

1 

3  1 

n 

0  1 

94  ft 

Y 

1 

N 

II 

Change.  Element 

ii 

4 

12  1 

ti 

0  1 

133  II 

Y 

1 

N 

II 

Retrieve  Element 

H 

3 

10  1 

N 

0  1 

121  H 

Y 

1 

N 

II 

Row.Slice 

N 

2 

12  1 

ii 

0  1 

137  R 

Y 

1 

N 

It 

Column  Slice 

II 

2 

12  1 

n 

0  1 

139  H 

Y 

1 

N 

II 

Add. to  Identity 

II 

2 

11  1 

n 

0  1 

113  il 

Y 

1 

N 

II 

Subtract  from.Identily 

II 

2 

11  1 

n 

0  1 

113  II 

Y 

1 

N 

N 

It 

2 

II  1 

H 

0  1 

112  II 

Y 

1 

N 

W 

II 

2 

11  1 

it 

0  1 

114  II 

Y 

1 

N 

II 

Vector  Senior  Operations  Unconstrained 

11 

15 

5  1 

ii 

142  1 

117  II 

N 

1 

N 

II 

If 

2 

20  1 

if 

0  1 

129  fl 

Y 

1 

N 

II 

T 

II 

2 

20  1 

n 

0  1 

129  fl 

Y 

1 

N 

II 

Vector  Scalar  Operations  Constrained 

H 

14 

3  1 

n 

139  1 

95  II 

N 

1 

Y 

II 

•••" 

II 

2 

II  1 

it 

0  1 

103  II 

Y 

1 

Y 

II 

T 

II 

2 

11  1 

n 

0  1 

103  II 

Y 

1 

Y 

H 

Matrix  Scalar  Operations  Unconstrained 

II 

19 

5  1 

n 

141  1 

118  II 

N 

1 

N 

n 

II 

2 

34  1 

ii 

0  1 

134  It 

Y 

1 

N 

II 

T 

n 

2 

34  1 

ii 

0  1 

135  II 

Y 

1 

N 

II 

Symmetric  Half  Storage  Matrix  Operations 

it 

12 

33  1 

ii 

148  1 

211  II 

N 

1 

N 

II 

Initialize 

ii 

3 

19  1 

ii 

0  1 

145  N 

N 

1 

N 

II 

Identity.  Matrix 

fi 

l 

5  1 

n 

0  1 

87  II 

Y 

1 

N 

II 

Zero_Matrix 

ii 

1 

5  1 

ii 

0  1 

85  If 

Y 

1 

N 

II 

Change.Element 

ii 

4 

14  1 

H 

0  1 

132  II 

Y 

1 

N 

II 

Retrieve  Etement 

n 

3 

13  1 

II 

0  1 

135  H 

Y 

1 

N 

II 

Row  Slice 

it 

2 

It  1 

II 

0  1 

134  H 

Y 

1 

N 

II 

Column  Slice 

ii 

2 

It  1 

II 

0  1 

137  II 

Y 

1 

N 

II 

Add_.to  Identity 

ii 

1 

13  1 

11 

0  1 

138  II 

Y 

1 

N 

II 

Subtract  from. Identity 

ii 

1 

16  1 

II 

0  1 

143  11 

Y 

1 

N 

II 

"+" 

ii 

2 

II  1 

II 

0  1 

143  II 

Y 

1 

N 

II 

ii 

2 

II  1 

II 

0  1 

144  II 

Y 

1 

N 

II 

S  wap.Col 

ii 

0 

7  1 

II 

0  1 

83  II 

N 

1 

N 

II 

Swap  Row 

ii 

0 

7  1 

II 

0  1 

83  It 

N 

1 

N 

II 

Symmetric  Full  Storage  Matrix  Operations 

ii 

1 

II 

1 

II 

1 

II 

Unconstrained 

ii 

10 

10  1 

II 

124  1 

99  II 

N 

1 

N 

(1 

Change  Element 

ii 

4  1 

24  1 

II 

0  1 

155  II 

Y 

t 

N 

II 

Set_to_Identity_Matrix 

ii 

1  1 

20  1 

II 

0  1 

141  II 

Y 

1 

N 

II 

Sct_to_Zero_Mntrix 

ii 

1  1 

3  1 

II 

0  1 

89  II 

Y 

1 

N 

II 

Add  to. Identity 

ii 

1  1 

22  1 

II 

0  1 

133  II 

Y 

1 

N 

II 

!  33 


TABLE  A -3.  CAMP  PARTS  SIZING  LIST  (7  OF  14) 


TLCSC  1  TLCSC  Name 

H 

Code  Size 

n 

Comment  Sire  H 

Pul 

11th 

II 

No.  1  Lower  Level  Units 

n 

Spec 

1  Body  1 

Teat  H 

Spec 

1  Body  II 

Uar 

II 

1  Subtract  from_ Identity 

ii 

1 

40  1 

II 

0 

174  II 

Y 

N 

II 

1  V 

ii 

2 

4ft  1 

II 

0 

152  (1 

Y 

N 

II 

ii 

2 

4ft  1 

II 

0 

151  H 

Y 

N 

II 

1  Matrix  Operations  Unconstrained 

ii 

9 

11  1 

II 

131 

113  II 

N 

N 

II 

1  V 

it 

2 

34  I 

II 

0 

13ft  II 

Y 

N 

II 

ii 

2 

34  1 

11 

0 

137  11 

Y 

N 

II 

1  *V 

ii 

2 

14  1 

II 

0 

112  tl 

Y 

N 

II 

ii 

2 

14  1 

II 

0 

112  II 

Y 

N 

II 

1  Set  to. Identity  Matrix 

ii 

1 

20  1 

II 

0 

142  II 

Y 

N 

II 

1  Sct_to_Zero  Matrix 

ii 

1 

5  1 

n 

0 

97  II 

Y 

N 

II 

| 

ii 

2 

38  1 

n 

0 

150  II 

Y 

N 

II 

1  Matrix  Operations  Constrained 

ii 

9 

9  1 

II 

115 

96  II 

N 

N 

II 

1  ’V 

ii 

2 

15  1 

II 

0 

97  II 

Y 

N 

II 

n 

2 

15  1 

II 

0 

9ft  II 

Y 

N 

11 

1  V 

ii 

2 

14  1 

II 

0 

97  II 

Y 

N 

II 

ii 

2 

14  1 

II 

0 

97  II 

Y 

N 

II 

1  Set_to_Identity_Matrix 

if 

1 

20  1 

II 

0 

119  II 

Y 

N 

II 

1  Set  to  _Zero_Matrix 

ii 

1 

5  1 

II 

0 

83  II 

Y 

N 

II 

1  Dynamically  Sparse  Matrix  Operations 

ii 

1 

II 

II 

II 

1  Unconstrained 

H 

9 

9  1 

H 

110 

100  II 

N 

N 

II 

1  Setjo  Identity  Matrix 

It 

1 

20  1 

N 

0 

137  II 

Y 

N 

II 

1  Set  to_Zero_ Matrix 

n 

1 

5  1 

II 

0 

96  II 

Y 

N 

II 

1  Add  to  Identity 

ii 

I 

26  1 

n 

0 

132  II 

Y 

N 

R 

1  Subtract  from_ldentity 

ii 

1 

33  1 

11 

0 

132  H 

Y 

N 

II 

1  'V' 

ii 

2 

44  1 

If 

0 

1311  It 

Y 

N 

It 

| 

ii 

2 

44  1 

II 

0 

137  II 

Y 

N 

II 

1  Dynamically  Sparse  Matrix  Operations  Constrained 

H 

ft 

9  1 

II 

110 

85  II 

N 

N 

II 

1  Set  to  Zero  Matrix 

H 

I 

5  1 

II 

0 

84  II 

Y 

N 

II 

1  Add,  to  Identity 

H 

1 

26  1 

II 

0 

117  II 

Y 

N 

II 

1  Subtract  from_Identity 

11 

1 

33  1 

II 

0 

IIS  It 

Y 

N 

II 

1  V* 

Ii 

2 

25  1 

II 

0 

105  It 

Y 

N 

II 

| 

II 

2 

25  1 

N 

0 

10ft  II 

Y  1 

N 

H 

1  Set  to_Identity .Matrix 

II 

1  1 

20  1 

II 

0 

117  II 

Y  1 

N 

II 

1  Vector  Operations  Unconstrained 

H 

13  1 

8  1 

n 

131  1 

115  II 

N  1 

N 

II 

1  V 

n 

2  1 

22  1 

n 

0  1 

125  11 

Y  1 

N 

II 

| 

it 

2  > 

22  1 

ii 

0  1 

124  II 

Y  1 

N 

II 

1  Dot.Produci 

ii 

2  1 

12  1 

n 

0  1 

138  It 

Y  1 

N 

ti 

1  Vector.  Length 

ii 

1  1 

23  1 

N 

0  1 

149  II 

Y  1 

N 

ii 

1  Vector  Operations  Constrained 

ii 

13  1 

7  1 

n 

120  1 

105  II 

N  1 

Y 

ii 

1  Dot  .Product 

ii 

2  1 

12  1 

H 

0  1 

131  H 

Y  1 

N 

u 

1  Vector.I-ength 

H 

1  1 

12  1 

II 

0  1 

113  II 

Y  1 

N 

it 

1  V 

n 

2  1 

11  1 

H 

0  1 

97  If 

Y  1 

Y 

ii 

| 

it 

2  1 

tl  1 

n 

0  1 

9ft  II 

Y  1 

N 

ii 

SUBTOTALS 

670 

2.36! 

3.792 

5.144 

14.791 

97 

17 

P6R3  1  Standard  Trig 

ii 

13  * 

79  1 

685  It 

189  1 

240  II 

N  1 

Y 

n 

1  Arctan2 

n 

11  1 

27  1 

II 

0  1 

125  W 

Y  1 

Y 

H 

1  Sin 

ii 

1  1 

5  1 

II 

0  1 

93  H 

Y  1 

N 

11 

1  Sin 

ii 

1  1 

4  1 

II 

0  1 

0  II 

Y  1 

N 

H 

1  Sin 

ii 

1  1 

4  1 

II 

0  1 

0  H 

Y  1 

N 

H 

1  Cos 

ii 

1  1 

5  1 

II 

0  1 

93  II 

Y  1 

N 

H 

1  Cos 

R 

1  1 

4  1 

11 

0  1 

0  II 

Y  1 

N 

H 

1  Cos 

H 

1  1 

4  1 

R 

0  1 

0  II 

Y  1 

N 

11 

1  Sin.Cos 

11 

3  1 

32  1 

II 

0  1 

140  II 

Y  1 

N 

11 

1  Sin.  Cos 

H 

3  1 

26  1 

H 

0  1 

II  II 

Y  1 

N 

II 

1  Sin.Cos 

R 

3  1 

26  1 

II 

0  1 

11  n 

Y  1 

N 

II 

1  Ton 

11 

1  1 

5  1 

II 

0  1 

93  II 

Y  1 

N 

II 

1  Tan 

H 

1  1 

4  1 

N 

0  1 

0  II 

Y  1 

N 

II 

1  Tan 

H 

1  1 

4  1 

It 

0  1 

0  II 

Y  1 

N 

n 

1  Arcsjn 

II 

1  1 

5  1 

II 

0  1 

91  II 

Y  1 

N 

ii 

1  Arcsin 

II 

t  1 

4  1 

II 

0  1 

0  II 

Y  1 

N 

ii 

1  Arcsin 

1! 

1  1 

4  1 

II 

0  1 

0  II 

Y  1 

N 

ii 

I  Arccos 

II 

1  1 

5  1 

II 

0  1 

91  II 

Y  1 

N 

ii 

1  Arccox 

II 

1  1 

4  1 

It 

0  1 

0  H 

Y  1 

N 

ii 

1  Arccos 

II 

1  1 

4  1 

(I 

0  1 

0  II 

Y  1 

N 

n 

1  Arcsin.Artcos 

II 

3  1 

10  1 

II 

0  1 

117  It 

Y  1 

N 

n 

1  Arcsin  Aiccos 

n 

3  1 

9  1 

II 

0  1 

0  II 

Y  1 

N 

ii 

1  Arcrin_Arccox 

ii 

3  1 

9  1 

II 

0  1 

0  II 

Y  1 

N 

n 

1  Arcton 

it 

1  1 

5  1 

II 

0  1 

91  II 

Y  1 

N 

ii 

134 


TABLE  A-3.  CAMP  PARTS  SIZING  LIST  (8  OF  14) 


n.csc 

1 

TLCSC  Namr 

II 

Code  Size 

II 

Comment  Size 

H 

P.rt 

1 

nth 

II 

No. 

1 

Lower  Level  Units 

II 

Spec 

1  Body  1 

Tex 

H 

Spec  1 

Body 

H 

1 

U» 

II 

7 

A  re  tan 

n 

| 

1  4  1 

7" 

0  1 

0 

T" 

Y 

1 

N 

II 

i 

Arctan 

N 

1 

1  4  1 

II 

0  1 

0 

ii 

Y 

1 

N 

It 

SUBTOTALS 

47 

217 

683 

0 

936 

23 

1 

P684 

i 

Geometric  Operations 

H 

7 

1  21  1 

392 

II 

109  1 

93 

H 

N 

T 

Y 

T 

i 

Unit  Radial  Vector 

H 

15 

1  22  1 

II 

107  1 

134 

n 

Y 

i 

Y 

it 

i 

Unit  Norma!  Vector 

II 

14 

1  13  1 

II 

101  1 

123 

n 

Y 

i 

N 

ii 

i 

Compute  Segment  and  Unit  Normal  Vector 

II 

21 

1  16  1 

II 

126  1 

140 

n 

Y 

i 

N 

n 

i 

Compute  Segment  and  Unit  Normal  Vector  w/  Arc* in 

n 

23 

1  16  1 

II 

130  1 

135 

ii 

Y 

i 

Y 

H 

i 

Oreat  Circle  Air  Length 

ii 

14 

1  29  1 

II 

122  1 

212 

ii 

Y 

i 

N 

n 

i 

Compute 

H 

4 

1  18  1 

It 

0  1 

8 

ii 

N 

i 

N 

ii 

SUBTOTALS 

91 

114 

392 

386 

732 

3 

2 

P686  1  Signal  Processing 

II 

14  1 

18 

1.180  N 

225  1 

102  8 

N 

1 

Y 

II 

1  Oeneral  Fir*t  Order  Filter 

II 

18  1 

14 

II 

108  1 

149  H 

Y 

1 

M 

II 

1  Update  Coefficients 

n 

0  1 

9 

II 

0  1 

99  n 

N 

1 

N 

II 

1  Filter 

n 

0  1 

11 

H 

0  1 

115  II 

N 

1 

N 

N 

1  Reinitialize 

ii 

0  1 

8 

N 

0  1 

81  n 

N 

1 

N 

II 

1  Tustin  Lead  Lag  Filter 

ii 

14  1 

12 

8 

105  1 

148  R 

Y 

1 

N 

fl 

1  Update  Coefficients 

n 

0  1 

7 

R 

0  1 

95  8 

N 

1 

N 

H 

!  Filter 

ii 

0  1 

12 

H 

0  1 

120  # 

N 

1 

N 

ft 

1  Reinitialize 

ii 

0  1 

6 

II 

0  I 

77  8 

N 

1 

N 

n 

1  Tustin  Lag  Filter 

ii 

14  1 

13 

II 

104  1 

143  II 

Y 

1 

N 

n 

1  Update  Coefficients 

ii 

0  1 

7 

H 

0  1 

95  II 

N 

1 

N 

ti 

1  Filler 

ii 

0  1 

10 

H 

0  1 

126  R 

N 

t 

N 

ii 

1  Reinitialize 

it 

0  1 

9  1 

II 

0  1 

81  R 

N 

1 

N 

ii 

1  Second  Order  Filter 

ii 

16  1 

23 

II 

113  1 

156  R 

Y 

1 

N 

ii 

1  Redefine  Coefficients 

ii 

0  1 

17  1 

II 

0  1 

101  8 

N 

1 

N 

n 

1  Filler 

ii 

0  1 

15  1 

H 

0  1 

123  8 

N 

1 

N 

ii 

1  Reinitialize 

ii 

0  1 

8  1 

n 

0  1 

84  II 

N 

1 

N 

it 

i  Tustin  Integrator  With  Limit 

ii 

16  1 

26  1 

H 

132  1 

230  R 

Y 

1 

N 

n 

1  Update  Limit 

ti 

1  1 

5  1 

N 

0  1 

109  R 

N 

1 

N 

ii 

1  Update  Gain 

n 

1  1 

3  1 

II 

0  1 

100  R 

N 

1 

N 

H 

1  Integrate 

it 

i  i 

29  1 

It 

0  1 

173  8 

N 

1 

N 

N 

1  React 

ii 

2  1 

10  1 

8 

0  1 

97  II 

N 

1 

N 

II 

1  Limit  Flag  Setting 

ii 

1  1 

3  1 

8 

0  1 

72  II 

N 

1 

N 

n 

1  Tuatin  Integrator  With  Asymmetric  Limit 

ii 

17  1 

29  1 

It 

139  1 

160  8 

Y 

1 

N 

II 

1  Update  Limits 

ii 

2  1 

9  1 

II 

0  1 

74  II 

N 

1 

N 

n 

1  Update  Gain 

H 

1  1 

3  1 

II 

0  1 

67  8 

N 

1 

N 

it 

1  Integrate 

It 

1  1 

36  1 

H 

0  1 

138  8 

N 

1 

N 

N 

1  Reset 

II 

2  1 

10  1 

II 

0  1 

8i  n 

N 

1 

N 

11 

1  Limit  Flag  Setting 

II 

1  1 

5  1 

N 

0  1 

62  II 

N 

1 

N 

II 

1  Upper  Lower  Limiter 

II 

8  1 

12  1 

It 

91  1 

129  II 

Y 

1 

Y 

II 

1  Update  Limits 

n 

2  1 

II  1 

II 

0  1 

97  8 

N 

1 

Y 

II 

1  Limit 

ii 

i  i 

13  1 

H 

0  1 

92  8 

N 

1 

Y 

II 

1  Upper  Limiter 

ii 

6  1 

7  1 

II 

79  1 

93  n 

Y 

1 

Y 

II 

1  Update  1  imit 

it 

1  1 

5  1 

II 

0  1 

85  R 

N 

1 

Y 

II 

1  Limit 

ii 

t  1 

ii  i 

n 

0  1 

94  II 

N 

1 

Y 

II 

1  Lower  Limiter 

ii 

6  1 

7  1 

H 

79  1 

98  II 

Y 

1 

Y 

II 

1  Update  Limit 

ii 

1  1 

6  1 

n 

0  1 

85  II 

N 

1 

Y 

II 

1  Limit 

ii 

1  1 

11  1 

ii 

0  1 

94  II 

N 

1 

Y 

II 

1  Absolute  Limiter 

ii 

6  1 

7  1 

H 

80  1 

107  II 

Y 

1 

Y 

II 

1  Update  Limit 

H 

1  1 

5  1 

II 

0  1 

92  II 

N 

1 

Y 

It 

1  Limit 

11 

1  I 

15  1 

II 

0  1 

99  II 

N 

1 

Y 

II 

1  Absolute  Limiter  With  Flag 

II 

6  1 

9  1 

It 

86  1 

121  II 

Y 

1 

N 

II 

1  Limit  Flag  Setting 

II 

1  1 

5  1 

II 

0  1 

76  II 

N 

1 

N 

H 

1  Limit 

II 

1  1 

18  1 

II 

0  1 

106  II 

N 

1 

N 

II 

1  Update  Limit 

It 

1  1 

5  1 

II 

0  1 

95  it 

N 

1 

N 

II 

SUBTOTALS 

152 

504 

1.180 

1.116 

4.721 

II 

12 

P687  1  Oeneral  Purpose  Math 

II 

18  1 

31  1 

1.061  R 

178  1 

82  II 

N 

t 

Y 

II 

i  Integrator 

II 

12  1 

9  1 

It 

91  1 

113  II 

Y 

i 

N 

II 

1  Reinitialize 

II 

2  1 

7  1 

II 

0  1 

65  II 

N 

I 

N 

II 

1  Update 

II 

1  1 

5  1 

II 

0  1 

60  II 

N 

1 

N 

II 

1  Integrate 

II 

4  1 

11  1 

N 

0  1 

75  H 

N 

1 

N 

II 

1  Interpolate  or  F.strapolnle 

II 

14  1 

14  1 

R 

82  1 

133  ft 

Y 

1 

N 

II 

1  Square  Root 

II 

7  1 

8  1 

N 

79  1 

no  ii 

Y 

1 

M 

II 

135 


TABLE  A-3.  CAMP  PARTS  SIZING  LIST  (9  OF  14) 


Tl.CSC  1  TLCSC  Name 

II 

Code  Size 

II 

Comment  Size  H 

Part 

11th 

II 

No,  1  Lower  Level  Units 

H 

Spec 

1  Body 

Teat  II 

Spec 

Body  II 

Uae 

II 

1  Sqri 

II 

1 

6 

II 

0 

N 

M 

II 

1  Root  Sum  Of  Squares 

II 

II 

9 

II 

B4 

89  II 

Y 

Y 

II 

1  Sign 

n 

3 

12 

II 

68 

92  II 

Y 

N 

tl 

1  Mean  Value 

if 

6 

10 

II 

75 

99  II 

Y 

N 

II 

1  Mean  Absolute  Difference 

H 

7 

19  1 

II 

75 

104  II 

Y 

N 

H 

1  Two  Way  Table  Lookup 

H 

28 

12  1 

II 

127 

111  II 

Y 

N 

II 

1  Initialize 

H 

4 

8  1 

II 

0 

0  II 

N 

N 

If 

1  Lookup Y 

II 

2 

54  1 

II 

0 

0  II 

N 

N 

II 

1  Lookup  X 

N 

2 

54  1 

n 

0 

0  II 

N 

N 

It 

1  Lookup  Table  Even  Spacing 

II 

12 

14  1 

ii 

130 

148  II 

Y 

N 

II 

1  Initialize 

n 

3 

7  1 

n 

0 

59  II 

N 

N 

II 

1  Lookup 

ii 

6 

33  1 

ii 

0 

107  II 

N 

N 

II 

1  Lookup 

H 

7 

46  1 

n 

108  II 

N 

N 

II 

1  Lookup  Table  Uneven  Spacing 

n 

15 

7  1 

ii 

120 

107  II 

Y 

N 

II 

1  Initialize 

n 

4 

10  1 

ii 

0 

60  II 

N 

N 

II 

1  Lookup 

n 

6 

24  1 

ii 

0 

94  II 

N 

N 

II 

1  Lookup 

it 

7 

36  1 

ii 

0 

97  II 

N 

N 

II 

1  Inc  re  men  lor 

n 

7 

8  1 

ii 

79  1 

102  II 

Y 

N 

II 

1  Reinitialize 

ii 

2 

7  1 

ii 

0  1 

71  II 

N 

N 

II 

1  Increment 

ii 

1 

6  1 

ii 

57  II 

N 

N 

II 

1  Dec  remen  tor 

ii 

7 

8  1 

ii 

79  1 

105  II 

Y 

N 

II 

1  Reinitialize 

ii 

2 

7  1 

ii 

62  II 

N 

N 

II 

1  Decrement 

n 

1 

6  1 

n 

0  1 

57  II 

N 

N 

II 

1  Running  Average 

H 

9 

9  1 

n 

83  1 

108  II 

Y 

N 

II 

1  Reinitialize 

II 

2 

7  1 

H 

0  1 

61  n 

N 

N 

II 

1  Reinitialize 

n 

1 

5  1 

N 

0  1 

56  H 

N 

N 

II 

1  Current  Average 

ii 

1 

7  1 

N 

0  1 

59  N 

N 

N 

H 

1  Accumulator 

8 

6 

9  1 

H 

77  1 

80  II 

Y 

Y 

It 

1  Reinitialize 

n 

1 

5  1 

It 

0  1 

37  II 

N 

Y 

II 

1  Accumulate 

ii 

1 

5  1 

II 

0  1 

56  II 

N 

Y 

tl 

1  Accumulate 

ii 

2 

B  1 

II 

0  1 

63  n 

N 

Y 

II 

1  Retrieve 

n 

1 

5  1 

It 

60  II 

N 

Y 

II 

1  Change  Calculator 

ii 

6 

B  1 

II 

73  1 

87  II 

Y 

N 

II 

1  Reinitialize 

it 

1 

5  1 

II 

0  1 

57  8 

N 

N 

II 

1  Change 

ii 

1 

8  1 

H 

0  1 

73  8 

N 

N 

II 

1  Retrieve  Value 

« 

1 

5  1 

II 

0  1 

54  II 

N 

N 

II 

1  Change  Accumulator 

ii 

7 

12  1 

H 

86  1 

109  II 

Y 

N 

II 

1  Reinitialize 

Ii 

3  1 

n 

57  II 

N 

N 

II 

1  Reinitialize 

2 

7  1 

N 

52  II 

N 

N 

II 

1  Accumulate  Grange 

li 

1 

6  1 

n 

0  1 

65  II 

N 

N 

II 

1  Accumulate  Orange 

II 

2 

9  1 

ii 

0  1 

70  H 

N 

N 

II 

1  Retrieve  Accumulation 

II 

1 

5  1 

ii 

0  1 

34  II 

N 

N 

II 

1  Retrieve  Previous  Value 

II 

1 

5  1 

ii 

54  II 

N 

N 

II 

SUBTOTALS 

234 

592 

1,061 

1.408 

3.629 

16 

6 

P688  1  Polynomial! 

8 

13 

15  1 

4.B13  It 

254  1 

129  n 

N  1 

Y 

II 

1  Reduction  Operations 

8 

7 

4  1 

H 

95  1 

99  n 

N  1 

Y 

II 

1  Sine  Reduction 

II 

I 

13  1 

II 

0  1 

74  n 

Y  1 

Y 

II 

1  Cosine  Reduction 

II 

1 

6  1 

II 

0  1 

74  II 

Y  1 

Y 

1! 

1  Taylor  Series 

n 

6 

B  1 

II 

129  1 

82  II 

N  1 

N 

II 

1  Taylor  Natural  Log 

It 

8 

17  1 

II 

89  1 

108  II 

N  1 

N 

II 

1  Nat  Log  Bterm 

II 

1 

18  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1  Not  Log  7 term 

II 

1 

17  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1  Nat  Log  6lerm 

H 

1 

16  1 

8 

0  1 

0  II 

Y  1 

N 

II 

1  Nat  Log  5term 

n 

1 

15  1 

II 

0  1 

0  II 

Y  1 

N 

It 

1  Nat  Log  4term 

n 

1 

14  1 

II 

0  1 

o  n 

Y  1 

N 

11 

1  Taylor  Log  Base  N 

ii 

9 

6  1 

II 

99  1 

110  II 

N  1 

N 

II 

1  Log  Base  N  Bterm 

n 

2 

4  1 

II 

0  1 

0  H 

Y  1 

N 

II 

1  Log  N  Bterm 

ii 

1 

4  1 

II 

0  1 

0  It 

N  t 

N 

II 

1  Log  Base  N  7term 

ii 

2  1 

4  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1  I-og  N  7term 

n 

1  I 

4  1 

It 

0  1 

0  II 

N  1 

N 

II 

1  Log  Base  N  6term 

n 

2  1 

4  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1  l,og  N  6term 

it 

1  1 

4  1 

II 

0  1 

0  II 

N  1 

N 

II 

f  Log  Base  N  5tcrm 

ii 

2  1 

4  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1  Ix>gN  5tcrm 

H 

I  1 

4  i 

It 

0  1 

0  II 

N  1 

N 

II 

1  Log  Base  N  4term 

ii 

2  1 

4  1 

II 

0  1 

0  It 

Y  1 

N 

II 

1  Log  N  4 term 

it 

1  1 

4  1 

II 

0  1 

0  H 

N  1 

N 

II 

1  Taylot  Degree  Operations 

ii 

10  1 

54  1 

II 

151  1 

206  It 

N  1 

N 

II 

1  Mod  Cos  D  4trrm 

n 

1  1 

32  1 

II 

0  1 

0  II 

Y  1 

N 

II 
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TABLE  A-3.  CAMP  PARTS  SIZING  LIST  (10  OF  14) 


TLCSC  1 
No  1 

TLCSC  Name 

Lower  Level  Units 

H 

II 

Code  Size 
Spec  1  Body  1 

N 

Teat  H 

Comment  Size  8 
Spec  1  Body  8 

Pul 

1 

1 

nth 

Uk 

II 

1 

Tan  D  flterm 

8 

f  1 

17  1 

8 

0  1 

0  8 

Y 

1 

N 

II 

I 

Mod  Tan  D8term 

II 

1  1 

J  1 

II 

0  1 

0  8 

Y 

1 

N 

II 

Mod  Tan  D7term 

II 

1  1 

5  1 

II 

n  i 

0  II 

Y 

1 

N 

II 

1 

Mod  Tan  PGterm 

II 

1  1 

3  1 

8 

0  1 

0  II 

Y 

1 

N 

II 

1 

Mod  Tan  D  .Verm 

8 

1  1 

3  1 

II 

0  1 

0  fl 

Y 

1 

N 

8 

1 

Mod  Ton  L)4term 

II 

1  1 

J  1 

II 

0  1 

0  8 

Y 

1 

N 

8 

1 

Sin  D  Bterm 

II 

1  1 

17  1 

II 

0  1 

0  II 

Y 

1 

n 

8 

1 

Sin  D  7term 

II 

1  1 

16  1 

II 

0  1 

0  II 

Y 

1 

N 

H 

1 

Sin  D  6»erm 

8 

1  1 

13  1 

II 

0  1 

0  II 

Y 

1 

N 

II 

1 

Sin  D  5term 

II 

1  1 

14  1 

II 

0  1 

0  II 

Y 

1 

N 

It 

1 

Mod  Sin  DfUerm 

II 

1  1 

34  1 

II 

0  1 

0  II 

Y 

1 

N 

il 

1 

Mod  Sin  D7term 

II 

1  1 

32  1 

II 

0  1 

0  8 

Y 

1 

N 

8 

1 

Mod  Sin  D  6trrm 

II 

1  1 

30  1 

II 

0  1 

0  8 

Y 

1 

N 

II 

1 

Mod  Sin  D  5 term 

8 

1  1 

28  1 

8 

0  1 

0  II 

Y 

1 

N 

H 

1 

Mod  Sin  D4tenn 

II 

I  1 

26  1 

II 

0  1 

0  8 

Y 

1 

N 

II 

1 

Cos  D  8  term 

8 

1  1 

25  1 

II 

0  1 

0  8 

Y 

1 

N 

II 

1 

Coa  D  7  term 

II 

1  1 

24  1 

II 

0  1 

0  8 

Y 

1 

N 

II 

1 

C©«  D  filerro 

8 

1  1 

23  1 

8 

0  1 

0  8 

Y 

1 

N 

H 

1 

Cos  D  5term 

It 

1  1 

22  1 

II 

0  1 

0  8 

Y 

1 

N 

N 

1 

Cos  D  4term 

II 

0  1 

27  1 

II 

0  1 

0  8 

N 

1 

N 

II 

1 

Mod  Cos  D  8 term 

fl 

1  1 

40  1 

II 

0  1 

0  M 

Y 

1 

N 

8 

1 

Mod  Cos  D  7term 

H 

1  1 

38  1 

n 

0  1 

0  8 

Y 

1 

N 

8 

1 

Mod  Cos  D  6 term 

n 

1  1 

36  1 

II 

0  1 

0  8 

Y 

1 

N 

8 

1 

Mod  Cos  D  5term 

ii 

1  1 

34  1 

8 

0  1 

0  8 

Y 

1 

N 

8 

1 

Sin  D  4term 

ii 

0  1 

19  1 

8 

0  1 

0  8 

N 

1 

N 

N 

1 

Taylor  Radian  Operations 

n 

13  1 

90  1 

8 

210  1 

249  N 

N 

1 

N 

8 

t 

Arc  tan  R  7  term 

ii 

1  1 

22  1 

8 

0  1 

0  8 

Y 

1 

N 

8 

1 

Arctan  R  6 term 

ii 

1  1 

21  1 

8 

0  1 

0  N 

Y 

1 

N 

II 

1 

Arctan  R  5 term 

ii 

1  1 

20  1 

8 

0  1 

0  8 

Y 

1 

N 

II 

1 

Arctan  R  4 term 

n 

1  1 

19  1 

8 

0  1 

0  8 

Y 

1 

N 

It 

1 

Alt  Arctan  R  8term 

n 

1  1 

16  1 

8 

0  1 

0  8 

Y 

1 

N 

II 

1 

Alt  Arctan  R  7 term 

n 

1  1 

15  1 

8 

0  1 

0  8 

Y 

1 

N 

8 

1 

Alt  Arctan  R  6tcrm 

ii 

1  1 

14  1 

8 

0  1 

0  8 

Y 

1 

N 

II 

1 

Ah  Arctan  R  5 term 

ii 

1  1 

13  1 

8 

0  1 

0  8 

Y 

1 

N 

8 

1 

AH  Arctan  R  4tenn 

H 

1  1 

12  1 

8 

0  1 

0  8 

Y 

1 

N 

8 

1 

Mod  Sin  R  6 term 

it 

1  i 

29  1 

8 

0  1 

0  8 

Y 

1 

N 

8 

1 

Mod  Sin  R  5 term 

8 

1  1 

27  1 

8 

0  1 

0  8 

Y 

1 

N 

II 

1 

Mod  Sin  R4trrm 

8 

f  1 

25  1 

8 

0  1 

0  8 

Y 

1 

N 

H 

1 

Co*  R  8  term 

n 

1  1 

25  1 

8 

0  1 

0  8 

Y 

1 

N 

II 

1 

Cos  R  7tenn 

ii 

1  1 

24  1 

8 

0  1 

0  II 

Y 

1 

N 

II 

I 

Coa  R  f»term 

ii 

1  1 

23  1 

8 

0  1 

0  II 

Y 

1 

N 

II 

1 

Coa  R  5term 

ii 

1  1 

22  1 

i; 

0  1 

0  8 

Y 

1 

N 

II 

1 

Coa  R  4term 

ii 

1  1 

21  1 

H 

0  1 

0  II 

Y 

1 

N 

8 

1 

Mod  Cos  R  8term 

ii 

1  1 

39  1 

ii 

0  1 

0  II 

Y 

1 

N 

II 

1 

Mod  Cos  R  7  term 

ii 

1  1 

37  1 

ii 

0  1 

0  II 

Y 

1 

N 

8 

1 

Mod  Cos  R  6term 

ii 

1  1 

35  1 

8 

0  1 

0  8 

Y 

1 

N 

II 

1 

Mod  Cos  R  5term 

ii 

1  1 

33  1 

8 

0  1 

0  II 

Y 

1 

N 

It 

Mod  Coa  R  4term 

ii 

1  1 

31  1 

II 

0  1 

0  II 

Y 

1 

N 

II 

1 

Tan  R  8term 

ii 

1  1 

16  1 

8 

0  1 

0  H 

Y 

1 

N 

II 

1 

Mod  Tan  R  8term 

ii 

I  1 

5  1 

II 

0  1 

0  II 

Y 

1 

N 

II 

1 

Mod  Tan  R  7term 

ii 

1  1 

5  1 

8 

0  1 

0  8 

Y 

1 

N 

II 

1 

Mod  Ton  R  6term 

ii 

1  1 

5  1 

II 

0  1 

0  II 

Y 

1 

N 

II 

1 

Mod  Ton  R  5term 

ii 

I  1 

5  1 

II 

0  1 

0  8 

Y 

1 

N 

II 

1 

Mod  Tan  R  4tenn 

ii 

1  1 

5  1 

8 

0  1 

0  It 

Y 

1 

N 

II 

1 

Arcain  R  8term 

8 

1  1 

16  1 

8 

0  1 

0  8 

Y 

1 

N 

II 

1 

Arcsin  R  7term 

II 

1  1 

15  1 

8 

0  1 

0  8 

Y 

1 

N 

II 

i 

Arcain  R  6term 

8 

1  1 

14  1 

II 

0  1 

0  II 

Y 

1 

N 

8 

1 

Arcain  R  Sterm 

II 

1  1 

13  1 

8 

0  1 

0  8 

Y 

1 

N 

II 

1 

Arccos  R  8 term 

II 

1  1 

16  1 

8 

0  1 

0  II 

Y 

I 

N 

II 

1 

Arccos  R  7 term 

II 

1  1 

15  1 

8 

0  1 

0  II 

Y 

1 

N 

II 

1 

Arccos  R  6term 

II 

I  1 

14  1 

8 

0  1 

0  II 

Y 

1 

N 

II 

I 

Arccos  R  5term 

II 

I  1 

13  1 

II 

0  1 

0  II 

Y 

1 

N 

8 

1 

Arctan  R  8term 

II 

1  1 

23  1 

II 

0  1 

0  II 

Y 

1 

N 

II 

1 

Sin  R  8 term 

II 

1  1 

16  1 

II 

0  1 

0  II 

Y 

1 

N 

II 

1 

Sin  R  7tcnn 

II 

1  1 

15  1 

II 

0  1 

0  II 

Y 

1 

N 

II 

1 

Sin  R  Glenn 

II 

1  1 

14  1 

II 

0  1 

0  8 

Y 

1 

N 

Ii 

1 

Sin  R  Stenn 

II 

1  1 

13  1 

8 

0  1 

0  II 

Y 

1 

N 

II 

1 

Sin  R  4temi 

II 

1  1 

12  1 

II 

0  1 

0  II 

Y 

1 

N 

II 

1 

Mod  Sin  R  8 term 

II 

1  1 

33  1 

II 

0  1 

0  II 

Y 

1 

N 

II 

1 

Mod  Sin  R  7 term 

II 

1  1 

31  i 

II 

0  1 

0  II 

Y 

1 

N 

Ii 
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TABLE  A-3.  CAMP  PARTS  SIZING  LIST  (11  OF  14) 


TLCSC 

No. 


TLCSC  Name 

Lower  Level  Units 

II 

H 

Spec 

Code  Size 

1  Body  1 

n 

Ten  II 

Comment  Size  8 
Spec  1  Body  II 

Pen 

1 

1 

nth 

Use 

II 

II 

Modified  Newton  Raphson 

8 

3 

8  1 

II 

76  1 

130  II 

N 

1 

Y 

"7 

SqRt 

ft 

4 

33  1 

N 

0  1 

0  8 

Y 

1 

Y 

ii 

Newton  Raphson 

H 

3 

9  1 

II 

76  1 

139  n 

N 

1 

N 

ii 

SqRt 

n 

4 

33  1 

II 

0  1 

0  Ii 

Y 

1 

N 

ii 

System  Functions 

II 

15 

10  1 

II 

72  1 

62  8 

N 

1 

N 

ii 

Semicircle  Operations 

II 

13 

22  1 

II 

114  1 

144  8 

N 

1 

N 

ii 

Sin 

n 

1 

7  1 

II 

0  1 

114  II 

Y 

1 

N 

n 

Cos 

it 

1 

7  1 

II 

0  1 

114  II 

Y 

1 

N 

ii 

Tan 

ii 

1 

8  1 

II 

0  1 

116  II 

Y 

1 

N 

n 

Arcsin 

ii 

1 

8  1 

II 

0  1 

129  II 

Y 

1 

N 

ii 

Arccos 

n 

1 

8  1 

It 

0  1 

129  II 

Y 

1 

N 

ii 

Arctan 

ii 

1 

7  1 

n 

0  1 

123  N 

Y 

t 

N 

ii 

Degree  Operations 

n 

7 

24  1 

n 

90  1 

122  II 

N 

1 

N 

ii 

Sin 

n 

1 

8  1 

8 

0  1 

108  H 

Y 

1 

N 

n 

Cos 

8 

1 

8  1 

ii 

0  1 

107  II 

Y 

1 

N 

ii 

Tan 

ii 

1 

8  1 

H 

0  1 

108  II 

Y 

1 

N 

8 

Arcsin 

n 

1 

8  1 

It 

0  1 

110  II 

Y 

1 

N 

II 

Arccos 

N 

1 

8  1 

H 

0  1 

110  8 

Y 

1 

N 

II 

Arctan 

n 

1 

7  1 

n 

0  1 

105  II 

Y 

1 

N 

II 

Square  Root 

N 

6 

8  1 

n 

74  1 

103  8 

Y 

1 

N 

II 

Sqrt 

H 

1 

8  1 

ii 

0  t 

108  II 

N 

1 

N 

II 

Base  10  Logarithm 

If 

7 

8  f 

it 

73  1 

103  II 

Y 

1 

N 

8 

Log  10 

II 

1 

8  1 

ii 

0  1 

108  II 

N 

1 

N 

II 

Base  N  Logarithm 

II 

11 

14  1 

ii 

97  1 

156  II 

Y 

1 

N 

II 

Log  N 

II 

1 

10  1 

n 

0  1 

125  II 

N 

1 

N 

II 

Radian  Operations 

II 

7 

21  1 

it 

90  1 

122  8 

N 

1 

N 

II 

Sin 

8 

1 

7  1 

n 

0  1 

104  8 

Y 

1 

N 

II 

Cos 

II 

\ 

7  1 

it 

0  1 

104  II 

Y 

1 

N 

II 

Tan 

8 

1 

8  1 

ii 

0  1 

108  H 

Y 

1 

N 

H 

Arcsin 

n 

1 

8  I 

ii 

0  1 

110  8 

Y 

1 

N 

II 

Arc  co* 

it 

I 

8  1 

8 

0  1 

110  H 

Y 

1 

N 

II 

Arctan 

n 

1 

7  1 

It 

0  1 

104  8 

Y 

1 

N 

II 

Cody  Waite 

ii 

4 

6  1 

II 

50  1 

82  N 

N 

1 

N 

II 

Cody  Natural  Log 

it 

8 

14  1 

H 

82  1 

114  H 

N 

1 

N 

II 

Nat  Log 

8 

I 

31  1 

8 

0  1 

0  II 

Y 

1 

N 

II 

R 

ii 

0 

6  1 

II 

0  1 

0  II 

N 

1 

N 

II 

De  float 

n 

0 

42  1 

8 

0  1 

0  II 

N 

1 

N 

II 

Cody  Log  Base  N 

H 

9 

6  1 

II 

91  1 

109  II 

N 

1 

N 

II 

Log  Base  N 

ii 

2 

4  1 

II 

0  1 

0  II 

Y 

1 

N 

II 

Ix»gN 

ii 

1 

4  1 

II 

0  1 

0  II 

N 

1 

N 

II 

Continued  Fractions 

ii 

3 

5  1 

n 

50  1 

76  II 

N 

1 

N 

II 

Continued  Radian  Operations 

8 

9 

4  1 

H 

98  1 

103  8 

N 

1 

N 

II 

Tan  R 

11 

3 

20  1 

It 

0  1 

0  8 

Y 

1 

N 

II 

Arctan  R 

II 

3 

25  1 

II 

0  1 

0  II 

Y 

1 

N 

II 

Fike 

II 

3 

5  1 

N 

50  1 

80  II 

N 

1 

Y 

II 

Fike  Semicircle  Operations 

8 

8 

10  1 

8 

91  1 

128  II 

N 

1 

Y 

II 

Arcsin  S  6term 

8 

1 

31  1 

N 

0  1 

0  8 

Y 

1 

Y 

8 

Arccos  S  6 term 

11 

1 

32  1 

8 

0  1 

0  8 

Y 

1 

Y 

II 

General  Polynomial 

11 

16 

4  1 

8 

126  1 

134  It 

N 

I 

N 

II 

Polynomial 

II 

1 

12  1 

II 

0  1 

0  8 

Y 

1 

N 

II 

Han 

n 

4 

6  1 

n 

55  1 

82  II 

N 

1 

N 

II 

Hart  Radian  Operations 

H 

II 

9  1 

il 

97  1 

122  8 

N 

1 

N 

II 

Cos  R  5term 

II 

1 

22  1 

II 

0  1 

0  II 

Y 

1 

N 

II 

Han  Degree  Operations 

II 

9 

9  1 

II 

95  1 

133  II 

N 

1 

N 

II 

Cos  D  5  term 

n 

1 

22  1 

It 

0  1 

0  II 

Y 

1 

N 

II 

Hastings 

N 

5 

6  1 

II 

55  1 

83  II 

N 

1 

N 

II 

Hastings  Degree  Operations 

8 

10 

18  1 

II 

114  1 

160  8 

N 

1 

N 

II 

Sin  D  5term 

n 

1 

14  1 

II 

0  1 

0  8 

Y 

1 

N 

II 

Sin  D  4terin 

ii 

1 

13  1 

II 

0  1 

0  II 

Y 

1 

N 

II 

Cos  D  5 term 

n 

1 

16  t 

II 

0  1 

0  II 

Y 

1 

N 

II 

Cos  D 4tcmi 

H 

1 

15  1 

8 

0  1 

0  II 

Y 

1 

N 

II 

Tan  D  5(erm 

it 

1 

12  1 

II 

0  1 

0  8 

Y 

1 

N 

8 

Tan  D4term 

ii 

1 

12  1 

II 

0  1 

0  II 

Y 

1 

N 

II 

Hastings  Radian  Operations 

ii 

12 

46  1 

II 

140  1 

216  II 

N 

1 

Y 

II 

Cos  R  5term 

ii 

1 

16  1 

II 

0  1 

0  II 

Y 

1 

Y 

II 

Cos  R  4term 

ii 

1 

15  1 

II 

0  1 

0  II 

Y 

1 

Y 

H 

Tan  R  5term 

ii 

1  1 

12  1 

If 

0  1 

0  8 

Y 

1 

Y 

II 

Tan  R  4term 

it 

1  1 

12  1 

II 

0  1 

0  II 

Y 

1 

Y 

II 

Arctan  R  Rterm 

ii 

1  1 

18  1 

II 

0  1 

0  It 

Y 

1 

Y 

II 

Arctan  R  7 term 

ii 

1  1 

17  1 

II 

0  1 

0  II 

Y 

1 

N 

II 
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TABLE  A-3.  CAMP  PARTS  SIZING  LIST  (12  OF  14) 


TLCSC  I  TLCSC  Name 

N 

Code  Size 

S 

Comment  Size  8 

Part 

1 

llth 

II 

No.  1  Lower  Level  Unit* 

8 

Spec  1 

Body  1 

Tent  II 

Spec  1 

Body  8 

1 

Une 

II 

1  Arctan  R  6term 

H 

1  1 

t«  i 

8 

0  1 

0  8 

Y 

n 

■a 

m 

1  Mod  Arctan  R  8temi 

n 

1  1 

21  1 

n 

0  1 

0  8 

Y 

i 

N 

BT 

1  Mod  Arctan  R  7lcrni 

it 

I  1 

27  1 

n 

0  1 

0  II 

Y 

i 

N 

W 

1  Mod  Arctan  R  6temi 

ii 

1  1 

26  1 

8 

0  1 

0  8 

Y 

i 

N 

1  Sin  R  5term 

H 

1  1 

14  1 

H 

0  1 

0  II 

Y 

km 

1  Sin  R  4term 

ii 

1  1 

1)  1 

ii 

0  1 

0  II 

Y 

i 

mk 

1  Chebyshev 

ii 

5  1 

7  1 

ii 

59  1 

78  8 

N 

i 

N 

ii 

1  Cbebyshev  Radian  Operation* 

ii 

10  t 

10  1 

ii 

103  1 

125  6 

N 

i 

N 

ii 

1  Sin  R  5temt 

n 

1  1 

26  1 

n 

0  1 

0  II 

Y 

i 

N 

ii 

1  Chebyshev  Degree  Operation* 

H 

9  1 

II  1 

ii 

91  1 

126  8 

N 

i 

N 

ii 

1  Sin  D  5term 

n 

1  1 

26  1 

ii 

0  1 

0  II 

Y 

i 

N 

it 

1  Chebyshev  Semicircle  Operations 

n 

9  1 

10  1 

n 

91  1 

125  8 

N 

i 

N 

ii 

1  Sin  S  5temi 

n 

1  1 

26  1 

H 

0  1 

0  8 

Y 

i 

N 

it 

SUBTOTALS 

424 

2.893 

4,813 

3.073 

6.513 

133 

IS 

P69I  1  Abstract  Data  Structures 

n 

8  1 

ii  i 

3,344  II 

185  1 

105  II 

N 

Y 

"7 

1  Bounded  Slack 

it 

21  1 

9  1 

If 

138  1 

133  8 

Y 

N 

ii 

1  Clear  Stark 

ii 

1  1 

5  1 

8 

0  1 

93  8 

N 

N 

ti 

1  Add_  Element 

ii 

2  1 

12  1 

8 

0  1 

137  8 

N 

N 

ii 

1  Retrieve_Element 

8 

2  1 

12  1 

H 

0  1 

139  8 

N 

N 

ii 

1  Peek 

II 

1  1 

10  1 

N 

0  1 

138  8 

N 

N 

n 

1  Stack  Status 

II 

1  1 

14  1 

6 

0  1 

125  8 

N 

N 

8 

1  Stack_Lengih 

II 

1  1 

3  1 

N 

0  1 

93  8 

N 

N 

II 

1  Unbounded  Stack 

8 

25  1 

10  1 

8 

152  1 

138  8 

Y 

N 

II 

1  Initialize 

II 

1  I 

16  1 

H 

0  1 

124  8 

N 

N 

II 

1  Clear  Stack 

II 

1  1 

IS  1 

8 

0  1 

142  8 

N 

N 

II 

1  Free_Memory 

N 

1  1 

13  1 

8 

0  1 

101  8 

N 

N 

II 

1  Add_Element 

n 

2  1 

16  1 

8 

0  1 

148  8 

N 

N 

II 

1  Retrieve^  Element 

n 

2  1 

IS  1 

8 

0  1 

150  8 

N 

N 

8 

1  Peek 

ii 

1  1 

12  1 

II 

0  1 

132  8 

N 

N 

8 

1  Stack  Status 

ii 

t  1 

14  1 

It 

0  1 

113  II 

N 

N 

II 

1  Stack_Length 

n 

1  1 

9  1 

II 

0  1 

108  6 

N 

N 

II 

1  Dot_Ne*t 

ii 

1  1 

5  1 

8 

0  1 

87  8 

N 

N 

II 

1  Set_Next 

H 

2  1 

6  1 

II 

0  1 

89  8 

N 

N 

II 

1  Unbounded  I'TPO  Buffer 

It 

25  1 

52  1 

8 

160  1 

233  II 

Y 

N 

8 

1  Inltlalize^BufTer 

fl 

1  1 

16  1 

H 

0  1 

111  H 

N 

N 

II 

1  Clear_Buffcr 

11 

1  1 

17  1 

8 

0  1 

126  8 

N 

N 

8 

1  Frte„Mcmory 

II 

1  1 

12  1 

II 

0  1 

132  8 

N 

N 

II 

1  Add_Elemcnt 

II 

2  1 

16  1 

n 

0  1 

144  8 

N 

N 

II 

1  Retrieve  Element 

H 

2  1 

IS  1 

8 

0  1 

156  8 

N 

N 

II 

1  Peek 

II 

1  1 

12  1 

8 

0  1 

124  II 

N 

N 

8 

1  Buffer  Status 

II 

1  1 

14  1 

II 

0  1 

106  II 

N 

N 

II 

1  Buffer  _Length 

II 

1  1 

9  1 

8 

0  1 

108  8 

N 

N 

II 

1  Dot_Ne*t 

II 

1  1 

5  1 

8 

0  1 

87  II 

N 

N 

II 

1  Set_Next 

II 

2  1 

6  1 

II 

0  1 

89  II 

N 

N 

8 

1  Nonblocking  Circular  Buffer 

n 

20  1 

9  1 

II 

147  1 

144  II 

Y 

Y 

II 

1  Clear_Buffer 

N 

1  1 

10  1 

If 

0  1 

100  8 

N 

Y 

II 

1  Add_Elemenl 

II 

2  1 

26  1 

II 

0  1 

125  8 

N 

Y 

II 

1  Retrieve  Element 

H 

2  1 

19  1 

II 

0  1 

137  II 

N 

Y 

II 

1  Peek 

II 

1  1 

17  1 

8 

0  1 

145  II 

N 

Y 

8 

1  Buffer  Status 

II 

1  1 

14  1 

8 

0  1 

123  It 

N 

Y 

II 

1  Buffcr_Length 

II 

1  1 

5  1 

8 

0  1 

92  II 

N 

Y 

II 

1  Unbounded  Priority  Queue 

It 

26  1 

32  1 

8 

174  1 

252  II 

Y 

Y 

II 

1  Queue  Status 

II 

1  1 

14  1 

8 

0  1 

106  8 

N 

Y 

II 

1  Queue_Length 

II 

1  1 

9  1 

8 

0  1 

113  8 

N 

Y 

H 

1  Dot_Ne>tl 

n 

1  1 

5  1 

8 

0  1 

87  8 

N 

Y 

8 

1  Set_Ne*t 

ti 

2  1 

6  1 

II 

0  1 

89  8 

N 

Y 

II 

1  Initialize 

H 

1  1 

16  1 

II 

0  1 

117  K 

N 

Y 

8 

1  Clear_Queue 

ti 

1  1 

18  1 

II 

0  1 

144  II 

N 

Y 

ft 

1  Free_  Memory 

ii 

1  1 

12  1 

8 

0  1 

115  8 

N 

Y 

II 

1  Add_F.lement 

ii 

3  1 

29  1 

II 

0  1 

172  II 

N 

Y 

II 

1  Retrieve  Element 

ii 

2  1 

IS  1 

II 

0  1 

143  II 

N 

Y 

II 

1  Peek 

ti 

1  1 

12  1 

II 

0  1 

121  II 

N 

Y 

II 

1  Bounded  FIFO  Buffer 

ii 

21  1 

9  1 

II 

168  1 

145  8 

Y 

Y 

ft 

1  Peek 

ii 

1  I 

IS  1 

8 

0  1 

141  II 

N 

Y 

II 

1  Buffer  Status 

ii 

1  1 

15  1 

8 

0  1 

124  II 

N 

Y 

II 

1  B  uffer_L.cn  gth 

ii 

1  1 

5  1 

II 

0  1 

92  II 

N 

Y 

II 

1  Clear_Buffer 

ii 

f  1 

10  1 

II 

0  1 

99  II 

N 

Y 

II 

1  Add  ^Element 

n 

2  1 

19  1 

II 

0  1 

143  il 

N 

Y 

II 
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TABLE  A-3.  CAMP  PARTS  SIZING  LIST  (13  OF  14) 


TLCSC  1 

TLCSC  Name 

H 

Code  Size 

n 

Comment  Size  II 

Pari  1 

1 1th 

II 

No. 

1 

Lower  Level  Units 

H 

Spec 

1  Body  1 

Teat  H 

Spec  1 

Body  H 

1 

Use 

II 

1 

Retrieve  Element 

jmrm 

0 

136  II 

N  1 

Y 

H 

1 

Available  Space  List  Operations 

N 

m 

0 

133  h 

N  1 

Y 

II 

1 

New  Node 

II 

/Jl 

0  1 

13ft  II 

N  1 

Y 

II 

1 

Save  Node 

II 

H 

0  1 

113  It 

N  1 

Y 

II 

1 

Save  List 

■fe 

II 

0  1 

H6  it 

N  1 

Y 

II 

SUBTOTALS 

204 

812 

3.344 

939 

7.331 

6 

29 

P692 

1 

Abstract  Processes 

II 

2 

1  0  1 

0  II 

0  1 

0  II 

Y  1 

M 

II 

1 

Finite  State  Machine 

It 

ft 

1  0  1 

II 

0  1 

0  II 

N  1 

N 

ft 

1 

Mealy  Machine 

H 

8 

1  0  1 

II 

0  1 

0  II 

N  1 

N 

H 

1 

Event-Driven  Sequencer 

II 

8 

1  0  1 

n 

0  1 

0  II 

N  1 

N 

II 

1 

Time-Driven  Sequencer 

N 

2 

1  0  1 

n 

0  1 

0  II 

N  1 

N 

ft 

1 

Sequence  Controller 

H 

3 

1  0  1 

it 

0  1 

0  II 

N  1 

N 

11 

SUBTOTALS 

29 

0 

0 

0 

0 

0 

0 

P*5 1 

1 

Unit  Conversions 

N 

144 

216  1 

961  II 

181  1 

173  H 

N  1 

Y 

"T 

1 

Kilograms  per  Meter  Squared  and  Pounds  per  Foot 

II 

1 

II 

1 

H 

1 

N 

1 

Squared 

H 

3 

2  1 

II 

0  1 

0  II 

N  1 

N 

II 

1 

Conversion  to  Pounds  per  Foot2 

II 

3 

7  1 

II 

0  1 

0  It 

Y  1 

N 

II 

1 

Conversion  to  Kilograms  per  Meter2 

N 

3 

7  1 

II 

0  1 

0  II 

Y  1 

N 

If 

I 

Radians  and  Semicircles  per  Second 

II 

5 

2  1 

II 

0  1 

0  II 

N  1 

N 

II 

1 

Conversion  to  Semicircles  per  Second 

It 

2 

4  1 

II 

0  1 

0  II 

Y  1 

N 

ft 

1 

Conversion  to  Radians  per  Second 

II 

2 

4  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1 

Degrees  and  Semicircles 

II 

5 

2  1 

II 

0  1 

0  ft 

N  1 

N 

II 

1 

Conversion  to  Semicircles 

N 

1 

4  1 

II 

0  1 

0  II 

Y  1 

N 

It 

1 

Conversion  to  Degrees 

H 

1 

4  1 

II 

0  1 

0  It 

Y  1 

N 

H 

1 

Degrees  and  Semicircles  per  Second 

II 

3 

2  » 

II 

0  1 

o  n 

N  1 

N 

II 

1 

Conversion  to  Semicircles  per  Second 

n 

3 

6  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1 

Conversion  to  Degrees  per  Second 

ii 

3 

6  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1 

Seconds  and  Minutes 

n 

5 

2  1 

n 

0  1 

0  ft 

N  1 

N 

H 

1 

Convert  ion  to  Minutes 

it 

l 

4  1 

ii 

0  1 

0  II 

Y  1 

N 

H 

1 

Conversion  to  Seconds 

H 

1 

4  1 

ii 

o  i 

0  II 

Y  1 

N 

II 

I 

Centigrade  and  Fahrenheit 

II 

5 

2  1 

ii 

0  1 

0  H 

N  1 

N 

II 

1 

Conversion  to  Fahrenheit 

II 

2 

6  1 

ii 

0  1 

0  II 

Y  1 

N 

II 

1 

Conversion  to  Centigrade 

II 

2 

6  1 

ii 

0  1 

0  II 

Y  t 

N 

II 

1 

Centigrade  and  Kelvin 

II 

3 

2  1 

ii 

0  1 

0  II 

N  1 

N 

ft 

1 

Conversion  to  Kelvin 

II 

1 

4  1 

ii 

0  1 

0  II 

Y  1 

N 

II 

1 

Conversion  to  Centigrade 

II 

1 

4  1 

ii 

0  1 

0  H 

Y  1 

N 

II 

1 

Fahrenheit  and  Kelvin 

II 

5 

2  1 

ii 

0  1 

0  II 

N  1 

N 

II 

1 

Conversion  to  Kelvin 

II 

1 

5  1 

ii 

0  1 

0  II 

Y  1 

N 

II 

1 

Conversion  to  Fahrenheit 

II 

1 

3  1 

ii 

0  1 

0  II 

Y  1 

N 

II 

1 

Kilograms  and  Pounds 

II 

5 

2  1 

ii 

0  1 

0  II 

N  1 

N 

II 

1 

Conversion  to  Kilograms 

II 

1 

4  1 

ft 

0  1 

0  II 

Y  1 

N 

II 

1 

Conversion  to  Pounds 

II 

1 

4  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1 

Meters  and  Feet  per  Second 

II 

5 

2  1 

II 

0  1 

0  II 

N  1 

N 

II 

1 

Conversion  to  Feet  per  Second 

II 

2 

5  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1 

Conversion  to  Meters  per  Second 

II 

2 

5  1 

II 

0  1 

0  H 

Y  1 

Y 

II 

1 

Meters  and  Feet  per  Second  Squared 

II 

5 

2  1 

II 

0  1 

0  II 

N  1 

N 

II 

1 

Conversion  to  Feet  per  Second! 

II 

2 

6  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1 

Conversion  to  Meters  per  Second2 

II 

2 

6  1 

II 

0  1 

0  ft 

Y  1 

N 

II 

1 

Ores  and  Meters  per  Second  Squared 

II 

5 

2  1 

II 

0  1 

0  II 

N  1 

N 

II 

1 

Con  vert  ion  to  Meters  per  Second2 

II 

2 

3  1 

II 

0  1 

0  II 

Y  1 

Y 

II 

1 

Conversion  to  Oees 

II 

2 

5  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1 

Gees  and  Feet  per  Second  Squared 

II 

3 

2  1 

H 

0  1 

0  II 

N  1 

N 

II 

1 

Conversion  to  Feet  per  Second2 

II 

2 

3  I 

II 

0  1 

0  II 

Y  1 

N 

II 

1 

Conversion  to  Oees 

II 

2 

5  1 

II 

0  1 

0  ft 

Y  1 

N 

Ii 

1 

Radians  and  Degrees 

It 

5 

2  1 

II 

0  1 

0  H 

N  1 

N 

II 

1 

Conversion  to  Degrees 

II 

I 

4  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1 

Conversion  to  Radinns 

II 

I 

4  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1 

Radians  and  Degrees  per  Second 

II 

5 

2  1 

II 

0  1 

0  II 

N  1 

N 

II 

1 

Conversion  to  Degrees  per  Second 

II 

2 

6  1 

II 

0  1 

0  II 

Y  1 

N 

II 

1 

Conversion  to  Radians  per  Second 

II 

2 

6  1 

II 

0  1 

0  II 

Y  1 

N 

It 

1 

Radians  and  Semicircles 

ft 

5 

2  1 

II 

0  1 

0  H 

N  1 

Y 

II 

1 

Conversion  to  Semicircles 

II 

1  1 

5  1 

II 

0  1 

0  II 

Y  1 

Y 

II 

1 

Conversion  to  Radians 

II 

1  1 

3  1 

II 

0  1 

0  II 

Y  1 

Y 

II 
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TABLE  A-3.  CAMP  PARTS  SIZING  LIST  (CONCLUDED) 


TLC5C 

1  TLCSC  Nome 

« 

Code  Size 

n 

Comment  Size 

II 

Pen  1 

llth 

II 

No. 

1  Lower  Level  Units 

n 

Spec 

1  Body  1 

1  Ted 

H 

Spec 

1  Body 

R 

1 

Use 

II 

1  Meter*  end  Feet 

dP 

■j  1  - 

D 

mm 

a 

N  1 

N 

1  Conversion  to  Feet 

II 

■a 

El 

i 

mm 

N 

1  Conversion  to  Meters 

Mi 

HI 

D 

■a 

a 

mm 

N 

SUBTOTALS 

141 

202 

961 

0 

0 

34 

55uU 

P*52 

1  External  Form  Conversion  Twos  Complement 

* 

35 

1  20  1 

241 

n 

236 

1  462 

a 

N  1 

Y 

1 

1  Scale 

II 

2 

1  9  1 

ii 

0 

1  143 

* 

KB 

N 

« 

1  Unacnle 

It 

2 

i  n  t 

" 

0 

1  '34 

n 

HI 

SUBTOTALS 

4 

17 

241 

0 

299 

2 

PS  90 

i  Quaternion  Operations 

n 

20 

1  9  1 

194 

H 

163  1 

1  72 

• 

N  1 

mm 

1  Quaternion  Computed  From  Euler  Angles 

ii 

15 

1  26  1 

K 

128  1 

1  19* 

R 

Y  1 

EM 

1  Normalized  Quaternion 

n 

3 

1  18  1 

R 

65  1 

1  131 

R 

Y  1 

N 

R 

4 

1  24  1 

n 

63  1 

1  126 

* 

EH 

MM 

SUBTOTALS 

22 

68 

194 

25* 

475 

3 

2 

TOTALS 

5.1% 

11.768 

29,043 

29,8*7 

63,532 

433 

173 

CODE  TOTALS 

16.964 

29,045 

95,419 

ORANDTOTAL  141.42* 
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3.  DATA  BASE  ISSUES 


Due  to  the  definition  and  nature  of  the  parts,  some  difficulties  arose  concerning  the  storage  of  infor¬ 
mation  about  parts  in  the  data  base.  Parts  may  be  TLCSCs,  LLCSCs,  or  units.  This  means  that  counting 
the  code  for  each  part  can  become  problematical  because  a  part  is  not  synonymous  with  an  Ada  structure. 
For  example,  a  package  may  contain  three  parts.  Obviously  the  specification  and  body  for  each  part  are 
counted  with  the  part,  but  what  about  code  for  the  encapsulating  package.  Can  that  be  allocated  to  each 
part  in  the  same  way?  The  problem  was  solved  by  representing  each  Ada  structure  in  the  data  base, 
whether  part  or  encapsulating  structure,  and  designating  whether  or  not  an  entry  was  a  part.  This  allows 
maximum  flexibility  as  to  parts  designation  while  at  the  same  time  allowing  all  the  Ada  code  to  be 
represented  and  counted  in  the  data  base. 

Another  difficulty  which  arose  concerned  the  hierarchical  nature  of  the  parts.  Because  the  parts  are 
implemented  as  a  collection  of  TLCSCs,  and  the  TLCSCs  are  packages  in  Ada,  the  parts  are  expressed  as 
a  hierarchy  of  packages  and  units.  In  order  for  the  parts  to  be  represented  in  the  data  base,  this  hierarchy 
must  be  represented  in  some  way  This  may  be  done  in  a  relational  data  base,  but  it  is  somewhat 
awkward.  ORACLE  provides  a  way  for  a  hierarchy  to  be  expressed,  but  in  order  to  do  so,  the  parent  unit 
of  each  part  needed  to  be  recorded  in  the  data  base.  This  awkwardness  made  the  generation  of  reports 
more  difficult  and  less  flexible. 

Because  no  single  field  could  uniquely  identify  an  entry  in  the  relations,  surrogates  were  used.  A 
surrogate  is  an  arbitrary  field,  usually  a  number,  which  is  used  as  the  prime  key  in  a  data  base.  The 
partno  column  in  each  of  the  relations  contained  this  surrogate  number.  The  surrogate  number  was  also 
used  to  identify  an  entry’s  parent.  Because  the  surrogates  enabled  entries  to  be  identified  uniquely  by  the 
use  of  only  one  field,  the  hierarchy  structure  was  considerably  simpler  than  if  more  than  one  field  had  to 
be  used  as  a  prime  key.  The  relations  were  also  indexed  to  provide  more  speed  in  referencing. 

4.  CONCLUSIONS  AND  RECOMMENDATIONS 

The  use  of  the  data  base  enhanced  CAMP  report  capabilities  in  several  areas.  The  first  was  the 
amount  of  time  spent  on  the  reports,  particularly  editing  and  formatting.  The  time  spent  editing  and 
reformatting  the  reports  must  be  balanced  against  the  lime  spent  learning  the  particular  data  base  used  and 
then  designing  the  data  base.  This  learning  time,  however,  was  a  one-time  expenditure  while  formatting 
and  editing  tasks  were  repeated  over  and  over. 

Report  availability  was  also  greatly  enhanced  by  the  use  of  the  data  base.  Before  the  data  base 
method  was  used,  up-to-date  reports  were  not  often  available  and  out-of-date  reports  were  used  because 
of  the  lime  required  to  redo  the  report.  With  the  data  base  method,  a  new  up-to-date  report  could  be 
generated  very  quickly  simply  by  running  the  report  program.  In  addition,  updates  were  very  easy  and 
could  be  made  as  they  occurred,  rather  than  waiting  to  have  enough  to  justify  spending  the  time  to 
reformat  the  entire  report. 

The  number  of  reports  was  increased  by  using  (he  data  base.  Because  the  report  generating  language 
had  to  be  learned  only  once,  additional  reports  took  only  a  fraction  of  the  time  to  write  than  the  initial 
report. 
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The  utilities  and  correlative  programs  also  made  the  use  of  the  ORACLE  data  base  productive. 
ORACLE  has  a  full  range  of  associated  programs  available  with  it  which  are  extremely  helpful.  In 
particular,  SQL*  Forms  made  the  data  base  interface  particularly  easy  and  productive  to  use.  Time  spent 
on  data  entry  was  considerably  reduced  and  new  people  were  able  to  use  the  interface  with  minimal 
instruction  (less  than  1  hour). 

SQL* Plus,  the  data  definition  and  manipulation  language,  also  made  the  use  of  the  data  base  produc¬ 
tive.  SQL*Plus,  based  on  the  standard  SQL  language,  is  a  very  rich,  yet  relatively  easy  to  use,  product. 
Its  use  made  many  data  base  tasks  such  as  the  relation  definition  easy.  Again,  productivity  needs  to  be 
measured  against  the  time  spent  learning  the  language,  but  SQL  is  relatively  standard  and  can  be  learned 
relatively  easily  by  a  novice  and  very  easily  by  anyone  with  experience  with  other  relational  data  base 
query  languages.  On  the  other  hand,  SQL*Plus  has  a  full  range  of  capabilities  which  can  satisfy  even  the 
most  complex  relational  application  requirements. 

The  use  of  a  data  base  for  these  types  of  report  and  information  storage  needs  is  highly  recom¬ 
mended.  A  number  of  lessons  concerning  the  use  of  the  data  base  came  to  light  during  the  CAMP  usage. 

•  Data  base  design  should  take  its  place  with  other  software  design  tasks  from  the  beginning  of  the 
project.  On  CAMP,  the  use  of  the  data  base  began  after  the  project  was  under  way.  Because  of 
this,  there  was  a  duplication  of  effort  when  the  change  was  made  from  using  a  hand-edited  report  to 
a  data  base.  To  avoid  this  type  of  duplication  of  effort,  it  is  recommended  that  a  project  start  with 
(he  data  base  from  the  beginning. 

•  Careful  attention  is  required  during  the  intial  design  and  layout  phase.  The  nature  and  extent  of  the 
data  already  collected  when  data  base  use  began  constrained  this  phase  during  CAMP.  As  a  result, 
the  first  set  of  data  base  relations  were  designed  with  little  knowledge  of  how  they  might  need  to  be 
expanded  or  used  at  a  later  date  with  other  data  base  relations.  This  resulted  in  less  flexibility  and 
more  difficult  generation  of  reports  later  on.  Careful  data  base  design  at  the  beginning  of  the 
project  will  reward  the  extra  time  spent  with  fewer  problems  later  on. 

•  The  use  of  ORACLE  is  recommended  for  this  type  of  data  base  use.  The  CAMP  project  found 
ORACLE  easy  to  use,  extremely  powerful,  and  with  an  excellent  set  of  utilities  and  con  dative 
programs.  ORACLE  has  the  added  advantage  of  using  SQL,  which  is  as  close  to  a  standard  as 
exists  for  query  languages,  and  is  available  on  a  wide  range  of  equipment. 
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APPENDIX  B 


CATALOG  ATTRIBUTES 

A  detailed  explanation  of  each  attribute  of  the  CAMP  software  parts  catalog  is  presented  here.  For  each 
attribute  the  following  information  is  provided  (as  applicable): 

1 .  The  name  of  the  attribute. 

2.  The  data  type  of  the  attribute.  The  type  of  an  attribute  can  be  NUMERIC  (e.g.,  Part  Number  is  a 
numeric  attribute),  STRING  (e.g.,  Part  Name  is  of  type  string),  SET  (e.g.,  the  Withs  attribute  may 
have  a  set  of  one  or  more  values),  TEXT  (e.g.,  the  value  of  Abstract  is  of  type  text),  or 
ENUMERATION  (e.g.,  the  Mode  attribute  must  have  a  value  of  bundled,  unbundled,  or 
schematic). 

3.  The  domain  of  an  ENUMERATION  type. 

4.  The  status  of  the  attribute.  This  is  either  REQUIRED  (i.e.,  all  parts  must  be  supplied  a  value  for 
this  attribute)  or  RECOMMENDED  (i.e.,  the  attribute  is  recommended  for  completeness  but  not 
required). 

5.  A  description  of  the  attribute's  meaning,  including  mention  of  any  default  values  and  the  source 
(user  or  system)  of  attribute  entry. 

6.  An  example  of  a  valid  value  is  shown  for  each  attribute. 

The  catalog  attributes  are  enumerated  in  Figure  B-l. 
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GENERAL 


Part  Number 
Part  Name 
Mode 
Class 

Last  Change  Date  of  Entry 
Government  Security  Classification  (part) 
Government  Security  Classification  (entry) 
Remarks 


Revision  Number 
Functional  Abstract 
Taxonometric  Category 
Keywords 
Project  Usage 

Corporate  Sensitivity  Level  (part) 
Corporate  Sensitivity  Level  (entry) 


DEVELOPMENT 


Design  Issues 
Development  Date 
Development  Status 
Requirements  Documentation 


Revision  Notes 
Developer 
Developed  For 
Design  Documentation 


USAGE 


Location  of  Source  Code 
Withs 

Implemented  By 
Built  From 
Sample  Usage 
Restrictions 


Access  Notes 
Wilhed  By 
Implements 
Used  to  Build 
Hardware  Dependencies 


PERFORMANCE 


Source  Size/Complexity  Characterizations 
Timing 


Fixed  Object  Code  Size 
Accuracy 


Figure  B-l.  Catalog  Attributes 
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ATTRIBUTE  NAME . Part  Number 


TYPE . Numeric 

STATUS . Required 

DESCRIPTION . Pari  Number  is  an  integer  which  together  with  the  value  of  the  Revision  Number 


attribute  uniquely  identifies  a  catalog  entry.  The  Part  Number  is  not  required  to 
be  unique  (i.e.,  the  same  number  would  be  used  for  ail  revisions  of  a  given  pari). 
The  Part  ID  code  will  consist  of  the  letter  P  followed  by  the  Part  Number 
hyphenated  with  the  Revision  Number,  and  will  be  generated  by  the  system.  The 
part  number  should  not  contain  leading  zeroes. 


EXAMPLE . 16 

ATTRIBUTE  NAME . Revision  Number 

TYPE . Numeric 

STATUS . Required 

DESCRIPTION . The  Revision  Number  is  an  integer  used  to  uniquely  identify  revisions  of  a  par¬ 

ticular  part.  The  revision  number  will  be  generated  by  the  system.  The  first 
entry  will  always  to  be  0,  with  subsequent  revision  values  incrementing  by  1. 
This  value  together  with  the  Part  Number  form  a  unique  key  called  the  Part  ED. 
EXAMPLE . 5 

ATTRIBUTE  NAME . Part  Name 

TYPE . String 

STATUS . Required 

DESCRIPTION . A  valid  Ada  identifier  which  provides  a  brief,  and  not  necessarily  unique, 

descriptive  name  for  a  part  (e.g.,  a  package  may  have  more  than  one  body,  in 
which  case  both  bodies  would  have  the  same  name  but  they  would  be  uniquely 
identifiable  by  the  Part  ID). 

EXAMPLE . Missile_Launch_P!atform 

ATTRIBUTE  NAME . Government  Security  Classification  of  Part 

TYPE . Enumeration 

DOMAIN . (Unclassified,  Confidential,  Secret,  Top_Secret) 

STATUS . Required 

DESCRIPTION . Specifies  the  DoD  security  classification  of  the  part.  The  default  value  is  Un¬ 

classified. 

EXAMPLE . Unclassified 

ATTRIBUTE  NAME . Corporate  Sensitivity  Level  of  Part 

TYPE . Enumeration 

DOMAIN . (Unclassified,  Private,  Sensitive,  Proprietary) 

STATUS . Required 

DESCRIPTION . Specifies  the  corporate  sensitivity  level  of  the  part.  The  default  value  is  Unclass¬ 

ified. 

EXAMPLE . Sensitive 
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ATTRIBUTE  NAME . Government  Security  Classification  of  Catalog  Entry 

TYPE . Enumeration 

DOMAIN . (Unclassified,  Confidential.  Secret,  Top_Secret) 

STATUS . Required 

DESCRIPTION . Specifies  the  DoD  security  classification  of  a  part’s  catalog  entry;  this  may  be 

different  from  the  security  classification  of  the  part  itself.  The  default  value  is 
Unclassified. 

EXAMPLE . Secret 

ATTRIBUTE  NAME . Corporate  Sensitivity  Level  of  Catalog  Entry 

TYPE . Enumeration 

DOMAIN . (Unclassified,  Private,  Sensitive,  Proprietary) 

STATUS . Required 

DESCRIPTION . Specifies  the  corporate  sensitivity  level  of  a  part’s  catalog  entry;  this  may  be 

different  from  the  corporate  sensitivity  level  of  the  part  itself.  The  default  value 
is  Unclassified. 

EXAMPLE . Proprietary 

ATTRIBUTE  NAME . Taxonometric  Category 

TYPE . Concatenation  of  enumeration  values 

DOMAIN . see  Figure  B-2 

STATUS . Required 

DESCRIPTION . Specifies  the  taxonometric  classification  of  the  part.  This  can  be  a  multi-leveled 

specification,  using  periods  to  separate  the  different  levels  of  classification. 
EXAMPLE . Primary  Operation.Navigation 

ATTRIBUTE  NAME . Functional  Abstract 

TYPE . Text 

STATUS . Required 

DESCRIPTION . A  brief  (no  greater  than  500  words)  explanation  of  the  purpose  and  functionality 

of  the  part.  This  attribute  is  intended  to  provide  the  user  with  a  quick  overview 
of  the  unit. 

EXAMPLE . The  bounded  FIFO  buffer  performs  buffering  of  data  in  a  first-in  first-out  fash¬ 

ion.  The  part  will  limit  the  number  of  items  which  may  be  in  the  buffer  at  any 
one  time  and  will  raise  an  exception  if  an  attempt  is  made  to  add  to  an  already 
full  buffer.  The  part  can  be  used  to  buffer  incoming  Mission  Data,  TERCOM 


processing,  or  DSMAC  updates.  In  addition,  this  part  can  be  used  for  message 
passing  between  components  of  a  system. 


ATTRIBUTE  NAME . Design  Issues 


TYPE . Text 

STATUS . Recommended 

DESCRIPTION . This  attribute  should  briefly  discuss  the  rationale  for  design  decisions  such  as  the 

selection  of  data  structures  and  algorithms  to  be  used.  The  user  should  be 
referred  to  external  design  documentation  for  a  lengthy  discussion  of  the  issues. 


This  field  should  contain  information  on  the  use  of  pragma  inline  for  the  part 
under  consideration. 

EXAMPLE . Since  the  telemetry  sampling  rale  changes  depending  upon  the  values  of  the  input 

data,  the  quantity  of  data  to  be  buffered  is  impossible  to  know  in  advance.  For 
this  reason,  dynamic  buffers  have  been  used  for  telemetry  data  storage  buffering. 
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ATTRIBUTE  NAME . Revision  Notes 

TYPE . Text 

STATUS . Recommended 

DESCRIPTION . This  attribute  should  briefly  describe  the  reason  for  revision,  and  any  changes  in 

functionality  that  have  occurred  as  a  result  of  the  revision. 

EXAMPLE . The  matrix  multiply  of  the  H  and  J  matrices  was  changed.  A  diagonal  matrix 

multiply  routine  is  now  utilized  rather  than  the  more  general  matrix  multiply 
routine  previously  used.  This  was  found  to  be  appropriate  for  every  case  and  the 
change  does  not  affect  functionality,  but  results  in  a  more  efficient  part. 

ATTRIBUTE  NAME . Class 

TYPE . Enumeration 

DOMAIN . (Package  Specification,  Package  Body,  Task  Specification,  Task  Body,  Sub¬ 
program  Specification,  Subprogram  Body,  Generic  Package  Specification, 

Generic  Package  Body,  Generic  Task  Specification,  Generic  Task  Body,  Generic 
Subprogram  Specification,  Generic  Subprogram  Body,  Generic  Formal  Part, 
Context  Clause) 

STATUS . Required 

DESCRIPTION . This  attribute  specifies  the  type  of  the  part.  The  word  type  is  not  used  for  this 

attribute  in  order  to  avoid  concision  with  Ada  types. 

EXAMPLE . Task  Body 

ATTRIBUTE  NAME . Keywords 

TYPE . Set  of  0  or  more  Strings 

STATUS . Recommended 

DESCRIPTION . This  attribute  contains  one  or  more  keywords  or  phrases  that  can  be  used  to 

locate  a  part.  Keywords  narrow  the  search  for  a  desired  part.  Keywords  can  be 
used  to  describe  functionality  of  the  part,  or  task  area.  Keywords  are  entered  for 
the  top-level  specification  only,  although  they  apply  to  the  lower  levels  as  well. 
EXAMPLE . (autopilot,  navigation) 

ATTRIBUTE  NAME . Mode 

TYPE . Enumeration 

DOMAIN . (Bundled  Code,  Unbundled  Code,  Schematic) 

STATUS . Required 

DESCRIPTION . This  attribute  indicates  the  part’s  usage  mode.  Bundled  parts  come  complete 

with  an  environment.  Unbundled  parts  consist  of  the  part  itself;  the  user  must 
establish  the  environment  in  which  it  is  to  be  used.  Schematic  parts  must  be 
constructed  from  the  constructors  provided. 

EXAMPLE . bundled  code 

ATTRIBUTE  NAME . Last  Change  Date  of  Entry 

TYPE . String 

STATUS . Required 

DESCRIPTION . This  attribute  provides  the  dale  that  the  catalog  entry  was  last  changed;  it  will  be 

supplied  by  the  system. 

EXAMPLE . 07-30-85 
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ATTRIBUTE  NAME . Development  Date 

TYPE . String 

STATUS . Required 

DESCRIPTION . This  attribute  provides  the  date  that  the  original  part  or  revision  was  developed;  it 

will  be  supplied  by  the  user. 

EXAMPLE . 02-22-85 

ATTRIBUTE  NAME . Developer 

TYPE . String 

STATUS . Required 

DESCRIPTION . This  entry  identifies  the  name  of  the  organization  that  developed  the  part.  The 

default  is  McDonnell  Douglas  Astronautics  Co. 

EXAMPLE . McDonnell  Douglas  Astronautics  Co. 

ATTRIBUTE  NAME . Developed  For 

TYPE . Set  of  strings 

STATUS . Recommended 

DESCRIPTION . This  attribute  should  identify  the  project  and  type  of  software  for  which  the  part 

was  originally  developed.  Multiple  entries  are  allowed  for  this  attribute. 
EXAMPLE . Tomahawk  (BGM- 109 AS)  Flight  Software 

ATTRIBUTE  NAME . Development  Status 

TYPE . Enumeration 

DOMAIN . (Specified,  Designed  &  Coded,  Tested,  Verified) 

STATUS . Required 

DESCRIPTION . This  attribute  indicates  the  development  status  of  the  unit.  If  the  value  is 


Specified,  this  indicates  that  the  need  for  and  purpose  of  the  part  have  been  iden¬ 
tified  and  the  requirements  have  been  specified  (all  required  attributes  except  for 
Mode,  Withs,  and  Withed  By  should  be  supplied  for  a  part  in  this  state).  If 
Designed  &  Coded,  the  requirements  for  the  part  have  been  refined  and  used  to 
specify  the  part  for  coding  in  Ada  so  that  compiled  code  is  now  available  (all 
remaining  attributes  may  now  be  supplied).  A  part  with  development  status  of 
Tested  indicates  that  this  part  has  passed  the  tests  of  the  developer  and  found  to 
be  in  working  condition.  Status  of  Verified  indicates  that  the  part  has  been  ac¬ 
cepted  and  verified  by  the  customer  for  which  it  was  originally  developed. 


EXAMPLE . Tested 

ATTRIBUTE  NAME . Source  Size/Complexity  Characterizations 

TYPE . Text 

STATUS . Recommended 

DESCRIPTION . This  attribute  provides  the  size  of  the  Ada  part  in  terms  of  lines  of  source  code 

(LOC),  and  other  complexity  characterizations. 

EXAMPLE . Lines  of  Source  Code: 


15  lines  executable 
2  lines  type  declarations 
5  lines  object  declarations 
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ATTRIBUTE  NAME . Fixed  Object  Code  Size 

TYPE . Text 

STATUS . Recommended 

DESCRIPTION . This  attribute  provides  the  fixed  (static)  size  of  the  Ada  part  in  terms  of  bytes  of 

object  code.  It  is  environment-dependent,  therefore,  the  conditions  under  which 
the  figure  was  obtained  must  be  provided. 

EXAMPLE . 720  bytes  when  compiled  on  VAX  1 1/780  using  the  VAX  Ada  compiler. 

ATTRIBUTE  NAME . Location  of  Source  Code 

TYPE . String 

STATUS . Recommended 

DESCRIPTION . This  entry  should  specify  the  file  name,  library,  and  computer  system  where  the 

source  code  for  the  part  or  part  constructor  is  located.  A  value  for  this  attribute  is 
entered  for  the  top-level  specification  only,  although  it  applies  to  the  lower  levels 
as  well. 

EXAMPLE . USERDISK5:[CAMP2.ABSTRACT]FSM.ADA 

ATTRIBUTE  NAME . Access  Notes 

TYPE . Text 

STATUS . Recommended 

DESCRIPTION . This  attribute  provides  access  information  for  a  particular  part.  To  deal  with 

actual  Ada  parts,  information  is  given  to  aid  in  applying  the  Ada  compilation 
rules  for  part  use,  such  as  what  other  parts  must  be  withed.  For  schematic  parts, 
information  is  given  on  how  to  get  to  a  particular  part,  such  as  how  to  invoke  the 
schematic  constructor. 

EXAMPLE . Include  the  statement  "with  Matrix_Types". 

ATTRIBUTE  NAME . Requirements  Documentation 

TYPE . Text 

STATUS . Recommended 

DESCRIPTION . This  attribute  identifies  the  requirements  documentation  and  indicates  its 

availability. 

EXAMPLE . Cruise  Missile  Advanced  Guidance  Computer  Program  Development  Specifica¬ 

tion  for  the  Inertial  Navigation  System,  Specification  #70H541092 

ATTRIBUTE  NAME . Design  Documentation 

TYPE . Text 

STATUS . Recommended 

DESCRIPTION . This  attribute  identifies  the  design  documentation  and  indicates  its  availability. 

EXAMPLE . Software  Detailed  Design  Document  for  the  Missile  Software  Parts  of  the  Com¬ 
mon  Ada  Missile  Packages  Project 

ATTRIBUTE  NAME . Withs 

TYPE . Set  of  identifiers  composed  of  Part  IDs 

STATUS . Required 

DESCRIPTION . This  attribute  contains  an  enumeration  of  other  units  within  the  catalog  that  this 

unit  withs. 

EXAMPLE . (PI 60-2,  P161-2) 
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ATTRIBUTE  NAME . Withed  By 

TYPE . Set  of  identifiers  composed  of  Part  IDs 

STATUS . Required 

DESCRIPTION . This  attribute  contains  an  enumeration  of  other  units  within  the  catalog  that  with 

this  unit. 

EXAMPLE . P70-0 

ATTRIBUTE  NAME . Project  Usage 

TYPE . Set  of  strings 

STATUS . Recommended 

DESCRIPTION . This  attribute  enumerates  the  projects  and  systems  that  use  this  particular  part. 

The  places  where  components  generated  via  constructors  are  used  should  also  be 
enumerated.  The  usage  attribute  aids  in  tracking  systems  which  have  ’checked  a 
part  out  of  the  library'.  Such  an  entry  facilitates  maintenance  in  the  event  that  an 
error  is  found  in  a  part. 

EXAMPLE . (AGM-109H,  AGM-109L,  Harpoon) 

ATTRIBUTE  NAME . Sample  Usage 

TYPE . Text 

STATUS . Recommended 

DESCRIPTION . This  attribute  provides  the  user  with  the  information  necessary  to  use  the  part 

(i.e.,  how,  when,  and  where  the  part  should  be  used).  Potential  usage  of  this  part 
in  the  applications  of  an  organization  may  be  discussed  here. 

EXAMPLE . This  part  is  generally  a  candidate  for  use  in  any  missile  which  has  a  throttleable 

engine  and  which  requires  the  control  of  mach  number. 

ATTRIBUTE  NAME . Accuracy 

TYPE . Text 

STATUS . Recommended 

DESCRIPTION . This  field  contains  information  on  the  algorithmic  accuracy  or  precision  of 

numerical  results  computed  by  the  part.  If  this  information  is  not  relevant,  it 
should  be  left  blank. 

EXAMPLE . The  distance  returned  has  an  accuracy  of  15  significant  digits. 

ATTRIBUTE  NAME . Timing 

TYPE . Text 

STATUS . Recommended 

DESCRIPTION . This  field  contains  information  on  execution  time  for  sample  invocations  or  in¬ 

stantiations  of  the  part.  The  run-time  conditions  that  produced  the  timing  results 
must  be  specified  in  order  to  make  this  information  relevant. 

EXAMPLE . This  part  averaged  an  execution  time  of  0.52  milliseconds  when  called  200  times 

from  a  continuous  loop  on  a  dedicated  Microvax  II. 

ATTRIBUTE  NAME . Implements 

TYPE . Set  of  identifiers  composed  of  Part  IDs 

STATUS . Recommended 

DESCRIPTION . This  attribute  is  valid  only  for  a  body,  and  identifies  the  specification  portion  that 

it  implements. 

EXAMPLE . P603-5 
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ATTRIBUTE  NAME . Implemented  By 

TYPE . Set  of  identifiers  composed  of  Part  IDs 

STATUS . Recommended 

DESCRIPTION . This  attribute  is  valid  only  for  a  Specification,  and  identifies  the  body  or  bodies 

that  implement  it. 

EXAMPLE . P603-5 

ATTRIBUTE  NAME . Built  From 

TYPE . Set  of  identifiers  composed  of  Part  IDs 

ST  A  TUS . Recommended 

DESCRIPTION . This  attribute  consists  of  an  enumeration  of  other  units  within  the  catalog  which 

are  encapsulated  within  this  unit;  these  are  the  parts  which  this  unit  is  built  from. 
The  entries  must  be  the  Part  IDs  of  these  parts.  Table  B-l  provides  guidelines  for 
determining  possible  built  from  relationships  for  parts. 

EXAMPLE . P603-5 

ATTRIBUTE  NAME . Used  to  Build 

TYPE . Set  of  identifiers  composed  of  Part  IDs 

STATUS . Recommended 

DESCRIPTION . This  attribute  consists  of  an  enumeration  of  other  units  within  the  catalog  which 

encapsulate  this  unit;  these  are  the  parts  which  are  used  to  build  the  current  part. 
The  entries  must  be  the  Part  IDs  of  these  parts.  Table  B-l  provides  guidelines  for 
determining  possible  used  to  build  relationships  for  parts. 

EXAMPLE . P603-5 

ATTRIBUTE  NAME . Hardware  Dependencies 

TYPE . Text 

STATUS . Recommended 

DESCRIPTION . This  entry  contains  an  elaboration  of  any  hardware  dependencies  of  the  part 

which  would  limit  its  transportability.  If  there  are  no  dependencies,  this  attribute 
will  show  None. 

EXAMPLE . 1553B  data  bus 

ATTRIBUTE  NAME . Restrictions 

TYPE . Text 

STATUS . Recommended 

DESCRIPTION . This  attribute  indicates  any  usage  restrictions  such  as  proprietary  rights  and 

copyrights. 

EXAMPLE . This  part  is  not  to  be  used  without  the  express  written  permission  of  McDonnell 

Douglas  Astronautics  Company. 

ATTRIBUTE  NAME . Remarks 

TYPE . Text 

STATUS . Recommended 

DESCRIPTION . This  field  is  for  any  general  remarks  concerning  the  part,  or  for  continuations  of 

other  fields, 

EXAMPLE . It  is  anticipated  that  future  missiles  will  use  the  structures  contained  in  this  part  to 

control  external  message  handling  and  to  support  dynamic  task  priorities  in  Ada. 
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*  Data  Package  Parts 

-  Data  Constant  Parts 

-  Data  Types  Parts 

*  Equipment  Interface  Parts 

-  General  Purpose  Equipment  Interface  Parts 

-  Specific  Equipment  Interface  Parts 

*  Primary  Operation  Parts 

-  Navigation  Parts 

-  Kalman  Filter  Parts 

-  Guidance  &  Control  Parts 

-  Non-guidance  Control  Parts 

*  Mathematical  Parts 

-  Coordinate  Vector/Matrix  Algebra  Parts 

-  General  Vector/Matrix  Algebra  Parts 

-  Trigonometric  Parts 

-  Geometric  Operations  Parts 

-  Data  Conversion  Parts 

-  Signal  Processing  Parts 

-  General  Purpose  Math  Parts 

-  Polynomial  Parts 

-  Sparse  Matrix  Algebra  Parts 

-  Quaternion  Algebra  Parts 

*  Abstract  Mechanism  Parts 

-  Abstract  Data  Structure  Parts 

-  Abstract  Process  Parts 

*  Process  Management  Parts 

-  Asynchronous  Control  Parts 

-  Communication  Paris 

*  General  Utility  Parts 

Figure  B-2.  CAMP  Parts  Taxonomy 
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TABLE  B-l.  USED  TO  BUILD'  AND  ’BUILT  FROM’  ATTRIBUTE  RELATIONSHIPS 


Part  Class 

Used  to  Build 

Built  From 

Package  Specification 

Package  Specification 
Subprogram  Body 

Package  Body 

Task  Body 

Package  Specification 
Subprogram  Specification 
Talk  Specification 

Package  Body 

Package  Specification 

Package  Specification 
Subprogram  Specification 
Task  Specification 

Subprogram  Specification 

Package  Specification 
Package  Body 

Task  Body 

Subprogram  Body 

Subprogi am  Specification 

Package  Specification 
Subprogram  Specification 
Task  Specification 

Task  Specification 

Package  Specification 
Subprogram  Body 

Package  Body 

Taak  Body 
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INITIAL  DISTRIBUTION  LIST 


GTE  GOVERNMENT  SYS  CORP 
ADVANCED  DIGITAL  SYSTEMS 
AFATL/FXG 

MILITARY  COMPUTER  SYSTEMS 
LOCKHEED/O/62-81,  B/563,  F15 
HUGHES/FULLERTON 
UNISYS/MS-E 1 D08 
WESTINGHOUSE/BALTIMORE 
AFWAL/AAAS-2 

BOOZ -ALLEN  A  HAMILTON,  INC 
BOEING  AEROSPACE  COMPANY/MS  8H-09 
BOEING  AEROSPACE  CO 
AD/YGE 

SOFTWARE  PRODUCTIVITY  CONSORTIUM 
ARMY  CECOM/AMSEL-COM-IA 
NAVAL  TRAINING  SYS  CENTER/CODE  251 
SCIENCE  APPLICATIONS  INTL  CORP 
RAYTHEON/MSL  SYS  DIVISION 
CALSPAN 

KAMAN  SCIENCES  CORPORATION 
NAVAL  RESEARCH  LAB/CODE  5595 
CARNEGIE  MELLON  UNIV/SEI/SHOLOM 
COLEMAN  RESEARCH  CORP 
COLS A,  INC 

CONTROL  DATA  CORPORATION 
WINTEC 

CONTROL  DATA/DEPT  1855 
DACS/RADC/COED 
RAYTHEON/EQPT  DIV 
BMO/ACD 
DDC-I,  INC 

ENGINEERING  A  ECONOMICS  RESEARCH/ 
DIV  OFFICE 
BDM  CORP 
AFATL/FXG/EVERS 
ESD/SYW-JPMO 

FORD  AEROSPACE  4  COMM  CORP/MS  H04 
UNIV  OF  COLORADO  #202 
ANALYTICS 
AFWAL/FIGL 

WESTINGHOUSE  ELECTRIC  CORP/MS  5220 

GENERAL  DYNAMICS/MZ  W2-5530 

HONEYWELL  INC 

TAMSCO 

STARS 

FORD  AEROSPACE/MS  2/206 
GRUMMAN  HOUSTON  CORPORATION 
NAVAL  AVIONICS  CENTER/NAC-825 
NASA  JOHNSON  SPACE  CENTER/EH/GHG 
BOEING  AEROSP ACE/MS-8 Y97 
HARRIS  CORPORATION/GISD 


1  CARNEGIE  MELLON  UNIV/ 

1  SOFTWARE  ENGINEERING  INST  1 

4  NOAA/ERL/R/E/AL4  1 
1  INTERMETRICS,  INC/G.  RENTH  1 
1  INTERMETRICS,  INC/D. P.  SMITH  1 
1  FORD  AEROSPACE/WEST  DEVEL  DIV  1 
1  AD/ENE  1 
1  ROC  KWELL/MS-GA2 1  1 
1  GRUMMAN  CORP/MS  D-3 1-237  1 
1  INSTITUTE  OF  DEFENSE  ANALYSIS  1 
1  TELEDYNE  BROWN/MS  178  1 
1  USAF/TAWC/SCAM  1 
1  BOEING  AEROSPACE  CO/D.  LINDBERG  1 

5  LOGICON  1 
1  EASTMAN  KODAK/DEPT  47  1 
1  SYSTEMS  CONTROL  TECH,  INC  1 
1  E-SYSTEMS/GARLAND  DIV  1 
1  AFWAL/AAAF  1 
1  MARTIN  DEVELOPMENT  1 
1  MA  COMPUTER  ASSOCIATES  INC  1 
1  IBM  FEDERAL  SYS  DIV/MC  3206C  1 
1  MCDONNELL  DOUGLAS/INCO,  INC  1 
1  UNITED  TECH,  ADVANCED  SYS  1 
1  MCDONNELL  AIRCRAFT  CO/DEPT  300  1 
1  WESTINGHOUSE  ELEC/MS  432  1 
1  MHP  FU-TECH,  INC  1 
1  ITT  AVIONICS  1 
1  COSMIC/UNIV  OF  GA  1 
1  NAVAL  OCEAN  SYS  CENTER/CODE  423  1 
1  NAVAL  WEAPONS  CTR/CODE  3922  1 
1  ODYSSEY  RESEARCH  ASSOCIATES,  INC  1 

USA  ELEC  PROVING  GRD/STEEP  MT-DA  1 
1  PATHFINDER  SYS  1 
1  BDM  CORPORATION  1 
1  PERCEPTRONICS,  INC  1 
1  PHOENIX  INTERNATIONAL  1 
1  MCDONNELL  DOUGLAS  ASTRO  CO  1 
1  GTE  LABORATORY/RUBEN  PRIETO-DIAZ  1 
1  PROPRIETARY  SOFTWARE  SYSTEMS  1 
1  ADVANCED  TECHNOLOGY  8 
1  STANFORD  TELECOMMUNICATIONS,  INC  1 
1  RATIONAL  1 
1  LOCKHEED  MISSILES  A  SPACE  CO  1 
1  HERCULES  DEFENSE  ELEC  SYS  1 
1  AEROSPACE  CORP  1 
1  ROGERS  ENGINEERING  A  ASSOCIATES  1 
1  ADASOFT  INC  1 
1  ESD/XRSE  1 
1  SANDERS/MER  24-1212  1 
1  CSC/ERIC  SCHACHT  1 
1  COMPUTER  TECH  ASSOCIATES,  INC  1 
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INITIAL  DISTRIBUTION  LIST  (CONCLUDED) 


SCIENCE  APPLICATIONS  INTER  CORP  1 
HQ  CASE/CBRC  1 
GOULD  INC/CSD  1 
HQ  AFSPACECOM/LKWD/STOP  32  1 
SVERDRUP/EGLIN  1 
HONEYWELL  INC/CLEARWATER  1 
TECHNOLOGY  SERVICE  CORP  1 
AEROSPACE/LOS  ANGELES  1 
SOFTWARE  ARCHITECTURE  &  ENGIN  1 
LORAL  SYSTEMS  GROUP/D/476-C2E  1 
NADC/CODE  7033  1 
UNISYS/PAOLA  RESEARCH  CTR  1 
SIRIUS  INC  1 
GENERAL  RESEARCH  CORP  1 
SOFTECH,  INC/R.L.  ZALKAN  1 
SOFTECH,  INC/R.B.  QUANRUD  1 
SOFTWARE  CERTIFICATION  INS  1 
SOFTWARE  CONSULTING  SPECIALIST  1 
SOFTWARE  PRODUCTIVITY  SOLUTIONS,  INC  1 
STAR-GLO  INDUSTRIES  INC  1 
NADC/CODE  50C  1 
WESTINGHOUSE/BALTIMORE  1 
MITRE  CORPORATION  1 
SYSCON  CORP/I.  WEBER  1 
SYSCON  CORP/C.  MORSE  1 
SYSCON  CORP/T.  GROBICKI  t 
AEROSPACE  CORPORATION/M-8-026  1 
TEXTRON  DEFENSE  SYSTEMS  1 
GENERAL  DYNAMICS/MZ  177^  1 
TIBURON  SYSTEMS,  INC  1 
TRW  DEFENSE  SYS  GROUP  1 
NASA  SPACE  STATION  1 
BALLISTIC  MSL  DEF  ADVANCED/ 

TECHNOLOGY  CENTER  1 
IBM  CORPORATION/FSD  1 
VISTA  CONTROLS  CORPORATION  1 
VITRO  CORPORATION  1 
NAVAL  RESEARCH  LABORATORY/CODE  5150  1 
CACI,  INC  1 
AFSC/PLR  5 
DIRECTOR  ADA  JOINT  PROGRAM  OFFICE  1 
MCDONNELL  DOUGLAS  ASTRONAUTICS/ 

E  H34/106/2/MS22  7 
SDIO/S/PI  '  1 
ADVANCED  SOFTWARE  TECH  SPECIALTIES  1 
DTIC-DDAC  2 
AFCSA/SAMI  1 
AUL/LSE  1 


FTD/SDNF  1 
AFWAL/FIES/SURVIAC.  1 
HQ  USAFE/INATW  1 
AFATL/CC  1 
AFATL/CA  1 
AFATL/DOIL  2 
6575  SCHOOL  SQUADRON  1 
IITRI  1 
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